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Abstract 


The  objective  of  this  research  was  to  design  and  validate  a  methodology  that  would 
enhance  the  productivity  of  the  buyers  who  perform  the  vendor  selection  function  at  the 
Defense  Electronic  Supply  Center. 

The  approach  utilized  computer  automation  and  software  developed  specifically  for 
this  application. 

A  prototype  was  developed  and  tested. 

Comprised  of  three  phases  and  eighteen  buyers,  the  testing  evaluated  the  prototype 
in  four  areas:  1)  accuracy  of  the  presented  information,  2)  thoroughness  of  the  presented 
information,  3)  ability  of  the  user  to  use  the  presented  information,  and,  4)  usability  by 
inexperienced  personnel. 

Examination  of  the  data  generated  by  the  test  phase  confirms  the  approach  used  to 
enhance  the  productivity  of  the  buyers  was  valid. 

As  a  result  of  findings  from  this  research,  the  recommendations  derived  include  the 
integration  of  this  methodology  into  the  development  of  future  buyer  assistance  programs. 
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PROCESS 


1.  Introduction 


Overview 

The  goal  of  this  thesis  is  to  show  that  improvement  is  possible  in  the  current  small 
contract  award  process  of  the  Defense  Electronics  Supply  Center  (DESC).  To  reach  this 
goal,  the  vendor  selection  process  must  first  be  understood.  This  includes  not  only  the 
tedious  mechanical  method  of  vendor  selection;  but  also  the  intuition  and  insight  brought 
to  the  problem  by  human  intervention.  The  procedure  used  to  complete  this  investigation 
began  with  an  analysis  of  the  current  selection  process.  After  the  analysis,  a  literary  review 
was  conducted,  searching  for  the  proper  technology  to  apply.  Finally,  a  prototype  system 
was  developed  to  test  the  theories  that  evolved  through  research.  The  following  pages 
document  the  process  performed  in  this  quest  to  improve  the  small  contract  vendor  selection 
process  at  DESC, 

Background 

About  DESC.  The  Defense  Electronics  Supply  Center  (DESC),  is  a  major  supply  center 
for  the  Defense  Logistics  Agency  ( 1 1:6).  It  is  the  principal  Department  of  Defense  activity 
for  the  procurement  and  management  of  electronic  spare  parts  (1 1:7).  In  1989,  DESC 
managed  almost  one  million  electronic  items  (Figure  1-1)  (12).  Their  involvement  in  this 
area  has  continued  to  grow  over  the  last  two  decades. 
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ITEMS  MANAGED 
BY  DESC  BY  YEAR 


1989 . 972,479 

1988 . 964,800 

1987 . 962,174 

1986 . 923,205 

1985 . 924,011 

1984 . 896,806 

1983 . 867,393 

1982 . 838,351 

1981 . 770,600 

1980 . 755,700 

1979 . 764,100 

1978 . 734,200 

1977 . 729,300 


FIGURE  1-1  —  Trends  in  Item  Management 


Last  year,  in  performing  its  mission,  one  hundred  fifty  one  buyers  at  DESC  entered 
into  contract  with  some  four  thousand  vendors,  resulting  in  the  award  of  one  hundred 
twenty-five  thousand  separate  contracts,  worth  six  hundred  four  million  dollars  (11). 
Eighty-seven  percent  of  these  contracts  were  given  to  small  and/or  disadvantaged  businesses 


(21). 


As  numerous  as  DESC’s  past  efforts  were,  their  workload  is  about  to  increase. 

On  November  1 1 ,  1989,  the  Secretary  of  Defense  directed  the  OSD 
staff  to  review  selected  Defense  Management  Report  Decisions  (DMRD), 
and  where  applicable,  develop  detailed  implementation  plans.  One  of  the 
DMRDs  encompassed  in  this  review  was  DMRD  926,  “Consolidation  of 
Inventory  Control  Points  (ICPs).”  (28;iii). 


On  July  3,  1990,  the  Deputy  Secretary  of  Defense  announced  the  approval  of  several 
recommendations  submitted  in  the  study  team’s  report.  Among  the  teams'  approved 
recommendations  was  to  “transfer  item  management  responsibility  for  approximately  one 
million  consumable  items  from  the  Military  Services  to  the  Defense  Logistics  Agency"  (5). 
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As  a  result,  DESC  will  gain  authority  for  an  additional  three  hundred  forty-eight  thousand 
separate  contract  items  (20). 

Small  Contract  Procurement  Process.  DESC  has  several  different  methods  for  selecting 
the  proper  supplier  of  a  product.  The  method  used  depends  upon  the  specific  requirements 
of  the  customer  and  the  item  itself.  The  dollar  value  of  the  contract  is  a  major  influence 
on  the  method  selected.  Low  value  contracts  comprise  a  significant  portion  of  DESC’s 
activities.  To  better  control  the  ever  increasing  volume  of  small  contract  awards, 
management  sees  a  need  to  improve  the  vendor  selection  process. 

For  each  item  inventoried,  there  is  a  person  responsible  for  assuring  an  adequate 
supply  exists  to  meet  the  users'  needs.  This  person  is  referred  to  as  the ‘Item  Manager’  (IM). 
The  item  manager  informs  the  ‘buyer’  at  DESC  how  many  units  of  the  item  must  be  ordered 
to  satisfy  the  demand.  The  document  identifying  this  requirement  is  the  ‘Purchase  Request’ , 
also  known  as  the  ‘PR’. .  Figure  1-2,  a  through  c,  illustrates  an  example  of  this  document. 

Each  buyer  at  DESC  is  responsible  for  a  specific  federal  stock  class  of  item.  All 
items  in  a  federal  stock  class  have  similar  characteristics.  For  example,  stock  class  5905 
contains  resistors,  while  stock  class  5910  contains  capacitors.  The  buyer  receives  the  PR 
identifying  the  part  or  product  required  and  is  responsible  for  selecting  the  appropriate 
vendor  for  contract  award.  To  reach  this  decision,  the  buyer  must  determine  which  vendor 
provides  the  item  at  the  lowest  cost.  However,  this  is  not  the  only  decision  factor.  Delivery 
time,  past  performance  and  other  government  guidelines  are  also  considered  (20). 

To  accomplish  this,  the  buyer  researches  price  and  vendor  information  to  compile 
a  comparative  analysis.  This  research  involves  examining  hard  copy  price  lists  (in  non- 
standardized  formats)  (Figure  1-3,  a  through  c)  and  obtaining  vendor  performance 
information  from  several  sources.  Finally,  the  buyer  must  consider  such  issues  as  vendor 
size  and  ownership  before  making  the  final  selection. 
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WRAP  MAT  •  XX:  CUSH/DUNN  MAT  =  XX:  CUS) /DUNN  THINESS  •  X: 
UNIT  CONT  •  XX:  LEVEL  PRESV  •  A:  INTRMITE  CONT  •  XX: 

INTRMDTE  CONT  QTY  •  XXX:  PACK  •  0:  PACI  ING  LEVS  1  •  C: 

MARKING  SHALL  BE  IN  ACCORDANCE  WITH  Mil -STD-129 SPECIAL  MAR 
KING  CODE:  99  -  NO  COOES  IN  THIS  TABLE  ONLY  MIL-STi:-129 

DOD  LOGMARS  BAR  CODE  MARKING  REQUIRED  1  AW  MI L-S PD- 1 2  9L , 
APPENDIX  M,  DATED  15  OCT  90  AND  MI L-STI -1189B , 

DATED  10  AUG  89. 

DELIVER  FOB:  BY: 


PARCEL  POST  /  FREIGHT  ADDRESS: 
SW0400 

DEFENSE  DEPOT  RICHMOND 
DEFENSE  GENERAL  SUPPLY  CENTER 
RICHMOND  VA  23297-5000 


CONTINUED  ON  NEXT  PAGE 


FIGlfRE  l-2^  --  Savii'I  I-:  Pi  «(  ham: 
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FIGURE  l-2c  —  Sami'I  I  Pi  kchasi-.  Ri  qi  i.st  (Coniim  i.i)) 
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QUANTITY  BREAKS 
RESALES 


PART  NUMBER 
RNC50H(1 ORO-1 503 )FS 
RNC50J(1 ORO-1 503 )FS 
RNCSUKd  ORO-1  503  )FS 
RNC55H(1 ORO-1 004 ) FS 
RNC55K(1  ORO-1  004  )FS 
RNC55H( 1 ORO-1 004 ) BS 
RNC55K( 1 ORO-1 004 ) es 
RNC55J  ( 1  ORO-1  004  ) FS 
RNC55 J  < 1 ORO-1  004  )BS 
RNC60H(1 ORO-1 004 )FS 
RNC60K( 1 ORO-1 004 ) FS 
RNC60J(1 ORO-1 004 )FS 
RNC60h(1 ORO-1 004 )BS 
RNC60 J(1 ORO-1 004 )BS 
RNC60K( 1 ORO-1 004 )BS 
RNC65H(1 ORO-1 004 )FS 
RNC65J(1 ORO-1 004 )FS 
RNC65K ( 1 ORO-1 004 ) FS 
RNC65H(1 ORO-1 004 )BS 
RNC65J ( 1 ORO-1 004 )BS 
RNC65K( 1 ORO-1 004 )BS 


QTY 

500 

.236 

QTY 

1  000 
.22  7 

.31  8 

.2  76 

.2  36 

.22  7 

.1  92 

.1  81 

.1  92 

.1  81 

.2  4 

.23 

.2  4 

.23 

.2  32 

.21  6 

.288 

.2  67 

.1  93 

.1  87 

.1  93 

.1  87 

.238 

.221 

.2  6 

.25 

.301 

.2  81 

.2  6 

.25 

.2  72 

.2  55 

.32  6 

.31  4 

.2  72 

.255 

.306 

.301 

.394 

.36 

.306 

.301 

UPDATE  EFFECTIVE  NOVEMBER  1.  1990.. .VALID  TIL  FURTHER  NOTICE 


FIGURE  I -3a  -  Sami’i.i;  Vi  NimK  Pkici.  Lists 
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FSCM:  6S313 

PHONE:  800-358-8708 
DATE:  4-01-90 


PRODUCT:  RESISTORS 
MIL-SPEC:  MIL-R-5Sie2 
MILITARY  TYPE:  RHC90Y 


CONFIDENTIAL  RESALE  PRICE  LIST  FOR  USE  BY  DESC  PROCUREMENT 
ESTABLISHED  RELIABILITY 


25- 

50- 

100- 

250- 

500- 

1000 

RANGE 

49 

99 

TO 

249 

499 

999 

&  UP 

*  •  • 

RNC90Y 

50.1  TO  49. 9K 

F(l') 

5.60 

5.22 

4.31 

4 . 09 

4.01 

3.92 

50.1  TO  49. 9K 

D(.51) 

6.30 

5.88 

4.95 

4 . 60 

4.51 

4.41 

SO. 1  CO  49. 9K 

3(.1\) 

7.01 

6.54 

5.39 

5.  12 

5 . 01 

4.90 

50.1  TO  49. 9K 

A( .05%) 

8.06 

7.52 

6.20 

5.89 

5.76 

5 . 64 

50.1  TO  49. 9K 

T( .01%) 

9.11 

8.50 

7.01 

6.66 

6-51 

6.37 

50. 1  TO  49. 9K 

V( .005%) 

11.91 

12.12 

9. 15 

8.69 

8.52 

8.33 

50K  TO  59. 9K 

F(l%)  ,, 

6.87 

6.16 

4 . 74 

4.51 

4.41 

4  .  32 

50K  TO  59. 9K 

D( . 5%) 

7.74 

6.94 

5.33 

5.06 

4 , 95 

4 .85 

5CK  TO  59. 9K 

S( . 1%) 

9.37 

8.40 

6.47 

6.14 

6.01 

5.89 

50K  TO  59. 9K 

A( .05%) 

10.77 

9.67 

7.44 

7.06 

0.92 

6.76 

SOK  TO  59. 9K 

T( .01%) 

11.16 

10.02 

7.71 

7.32 

7  .  17 

7.01 

5CK  TO  59. 9K 

V( .005%) 

14. 61 

13.10 

10.07 

9.57 

9.37 

9.17 

60K  TO  99. 9K 

F(  1%) 

8.  13 

7.28 

5.60 

5  .  32 

5.21 

5  .  10 

60K  TO  99. 9K 

D( . 5%) 

9 . 14 

0. 19 

6.30 

5.98 

5.06 

5 . 74 

60K  T099.9K 

B( .  1%) 

10.15 

9.10 

7.01 

6.66 

6.51 

6.37 

60K  TO  99. 9K 

A( . 05% ) 

11.68 

10.46 

8.06 

7.65 

7  .  49 

7  .  33 

6CK  TO  99. 9K 

T( .01% ) 

13.20 

11.84 

9.09 

8.65 

8.46 

8.19 

60K  TO  99. 9K 

V( . 005% ) 

17.27 

15.47 

11.91 

11.31 

11.07 

10.83 

••  MINIMUM  ORDER  25  PCS  ** 


M,  P,  OR  R  LEVEL  TOLERANCE 
S  LEVEL  TOLERANCE  ADD  401 


Problems.  The  following  problems  have  been  identified  with  the  current  process. 

Inefficiencies.  The  current  process  appears  to  house  inefficient  procedures.  As  an 
example,  each  buyer  maintains  separate  price  lists  provided  by  each  vendor.  There  is  no 
standardization  between  vendors  regarding  the  format  in  which  the  information  is 
portrayed.  There  is  no  consistency  in  the  arrangement  of  the  part  numbers,  quantity  price 
breaks,  or  lot  size  offered  (Figure  1-3,  a  through  c).  The  ‘uniqueness’  of  each  price  list 
examined  by  the  buyer  leads  to  needless  delay  in  retrieving  the  required  information  (20). 

The  vendor  submits  price  lists  to  DESC  for  each  parts  class  offered.  Each  time  the 
prices  change,  the  vendor  submits  an  updated  list.  DESC  routes  these  lists  to  the  proper 
buyers  for  their  use.  Should  thebuyer  complete  a  vendor  awrrd  using  outdated  information, 
(i.e. ,  before  receiving  and  posting  the  current  prices),  a  delay  in  item  shipment  may  result 
until  resolution  of  the  differences  is  reached. 

Guidance.  In  awarding  small  contracts,  the  buyers  consult  several  government 
guidelines  before  determining  which  vendor  will  receive  the  contract.  These  guidelines  are 
not  binding.  Rather,  the  guidelines  suggest  what  characteristics  the  vendor  should  possess 
to  receive  a  contract. 

With  these  many  inputs  into  the  decision  process,  management  has  voiced  a  concern 
regarding  the  accuracy  of  the  decisions  being  made.  Not  only  is  the  correctness  of  fhe 
decision  an  issue,  but  the  latitude  inherent  to  the  selection  process  makes  it  difficult  to  justify 
why  a  given  decision  was  made  (18). 

The  absence  of  structure  makes  maintenance  of  the  needed  information  a  challenging 
task.  Standardizing  the  presentation  of  the  data  could  accelerate  the  selection  process. 
Furthermore,  it  would  ease  the  task  of  the  buyers  as  well  as  reduce  processing  time  if  they 
were  not  required  to  calculate  rudimentary  figures  such  as  the  extended  price  from  the  unit 
price  for  each  vendor. 
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VASPP  Concept.  Improvement  in  the  small  contract  award  process  is  only  part  of  a  greater 
vision  of  Col.  Hewett  and  Mr.  Vicars  from  DESC-P  (18).  VASPP  (Vendor  Automated 
Supplied  Pricing  Program)  (Figure  1-4)  is  an  encompassing  program  concept  that  will  focus 
on  competitive  small  purchases  under  twenty-five  thousand  dollars  (16:2).  Under  this 
concept,  the  manufacturers  and  distributors  (vendors)  of  an  item  will  submit  and  update  their 
prices  to  DESC  via  electronic  means  for  inclusion  into  a  centralized  database.  Once 
received,  the  buyer  would  have  access  to  the  latest  revisions  of  the  vendor  pricing 
information. 


FIGURE  1-4  -  Th;;  VASPP  Contiit 


DESC  expects  VASPP  will  aid  the  organization  through  enhancements  in  several 


areas.  Among  them: 


-  Potential  to  realize  significant  ALT  [Administrative  Lead  Time] 
savings  with  reasonable  investment  of  resources  for  development  and 
maintenance  of  the  program. 

-  Resource  savings  from  reduced  administrative  efforts;  for  example, 
avoid  clerical  function  of  inputting  quotes/altemate  bids. 

-  Focuses  on  small  purchase  arena  which  represents  ninety-eight 
percent  of  procurement  actions  and  sixty  percent  of  obligated  dollars. 

-  Maintains  ready  source  of  supply  without  some  of  the  disadvan¬ 
tages  (e.g.,  pricing,  exclusivity,  and  resource  demands)  of  long  term 
contracts.  (16) 


Scope  of  Research 

Specific  Problem.  The  current  system  used  for  small  contract  award  determination  requires 
a  significant  amount  of  labor  to  acquire  the  most  basic  of  data.  In  addition,  to  maintain  the 
ability  of  making  the  appropriate  decisions,  the  buyer  must  be  ever  vigilant  for  changing 
information  from  many  sources.  As  a  result,  there  is  degradation  in  the  award  process  and 
doubts  have  arisen  concerning  the  quality  of  the  resulting  decision  (18). 

Research  Objective.  The  overall  goal  of  this  project  is  to  determine  whether  improvements 
in  the  current  small  contracting  process  are  possible.  To  reach  this  end,  the  first  objective 
is  to  identify  the  information  requirements  of  the  current  award  process.  The  next  objective 
is  to  develop  a  ‘tool’  for  the  buyer.  To  fulfill  the  needs  of  the  primary  users  (the  buyers), 
it  should  be  responsive,  and  identify  those  vendors  best  meeting  cost,  performance  and  other 
governmental  guidelines.  The  third  objective  is  to  confirm  whether  the  designed  system 
actually  enhances  the  current  process. 

Research  Questions.  To  meet  the  objectives  of  this  research  project  an  answer  is  needed 
for  the  following  questions: 
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1.  What  information  must  the  buyer  obtain  before  selecting  the  proper 
vendor? 

2.  What  information  does  the  buyer  generate  while  awarding  a  contract  to 
the  vendor? 

3.  What  automated  management  systems  are  available,  and,  of  these 
systems,  which  ones  could  satisfy  the  needs  of  DESC,  given  the  type  of 
data  available  and  the  results  required? 

4.  Can  an  effective  automated  system  be  designed,  developed  and  em¬ 
ployed  to  assist  the  buyer's  vendor  selection  process  at  DESC? 

Areas  of  Study.  The  bounds  of  this  study  are  limited  to  actions  directly  related  to  improving 
the  small  contract  vendor  selection  process  at  DESC.  The  proposed  solution  shall  take  a 
purchase  request  input  by  the  buyer  and  identify  the  vendor(s)  that  is(are)  competitive  on 
that  product.  Efforts  will  focus  on  the  development  of  a  fully  functional  computer  based 
prototype  system.  To  aid  in  future  integration  into  the  current  data  processing  environment, 
the  prototype  will  maximize  the  use  of  data  already  available  from  the  computer  systems 
at  DESC. 

Method  of  Organization.  This  paper  documents  the  research  conducted  using  six  chapters. 
Chapter  One  identifies  the  problem  as  described  by  DESC,  and  provides  background 
information  directing  this  research.  Chapter  Two  contains  the  literature  review  conducted 
for  this  project.  It  focuses  on  the  various  methods  of  computer  based  management  systems 
and  software  verification.  Chapter  Three  describes  the  methodology  used  to  develop  a 
solution  to  the  research  problem.  Chapter  Four  describes  the  development  and  verification 
of  the  system  software.  Chapter  Five  includes  the  analysis  of  the  prototype  validation 
process.  Finally.  Chapter  Six  summarizes  the  research  findings  and  provides  recommen¬ 
dations  for  future  actions. 
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II.  Literature  Review 


Overview 


In  support  of  this  research,  Chapter  I  identified  the  following  research  question:  ‘What 
automated  management  systems  are  available,  and,  of  these  systems,  which  ones  could 
satisfy  the  needs  of  DESC,  given  the  type  of  data  available  and  the  results  required?’ 
Required  to  address  this  question  is  the  examination  of  two  supporting  questions: 

1.  Whattypeofcomputerassistantsystemscansatisfy DESC’s  requirements? 

2 .  What  are  the  strengths  and  weaknesses  of  the  systems  under  consideration? 

Once  a  system  is  selected  and  designed,  the  program  coding  must  be  verified. 
Additional  research  was  conducted  in  this  area  to  answer  the  following  question:  ‘Once 
developed,  how  can  the  system  be  verified?’ 

The  findings  from  these  questions  can  be  used  to  answer  Research  Question  number 
three.  The  information  obtained  will  affect  the  structure  of  the  proposed  system,  and 
consequently  how  the  system  will  be  tested. 

Prototyping 

The  total  VASPP  concept,  (explained  in  Chapter  I)  which  this  research  supports, 
extends  well  beyond  the  scope  of  this  project.  There  is  little  guidance  regarding  the  final 
structure  V  ASPP  will  assume.  Asa  result,  the  author  views  these  efforts  as  a  prototype  from 
which  future  developments  will  spawn.  Initial  prototyping  is  an  effective  method  fordeating 
with  ideas  that  have  yet  to  solidify. 

This  design  strategy,  known  as  prototyping,  has  proven  to  be  useful 
across  a  wide  range  of  informational  systems’  applications.  In  general, 
prototypes  have  been  shown  to: 
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(1)  improve  the  likelihood  of  developing  systems  desired  by  users, 

(2)  shorten  the  overall  development  period, 

(3)  reduce  management  risk,  and 

(4)  serve  as  specifications  for  further  (later)  system  development.  (7:94) 
Computer  Assistant  Systems 

This  portion  of  the  literature  review  addresses  the  first  set  of  supporting  questions. 
For  the  purposes  of  this  research,  the  phrase  ‘Computer  Assistant  System’  refers  to  an 
application  of  computer  technology  that  aids  the  user  in  the  decision  making  process. 

Before  proceeding  with  the  review,  it  is  helpful  to  summarize  what  is  known  thus 
far  concerning  DESC’s  requirements.  First,  DESC  would  like  to  simplify  the  small  vendor 
selection  process.  Areas  appearing  to  have  latitude  for  improvement  are:  standardizing  the 
vendor  price  lists,  providing  the  buyer  with  past  procurement  information,  and  reducing 
the  need  to  perform  routine  calculations. 

Secondly,  DESC  would  like  to  use  the  results  of  this  project  as  a  baseline  for  the 
VASPP  program.  If  successful,  this  research  will  lay  the  foundation  on  which  to  build 
follow-on  development  efforts. 

Systems  Reviewed. 

Database  Management  Systems  (DBMSsi.  Database  management  systems  are  a 
means  of  keeping  current  information  in  a  readily  accessible  format  ayailable  for  conyenient 
review.  “.  .  .  a  data  ha.se  niana^emenf  system  (DBMS)  is  generally  defined  as  a  collection 
of  computer  programs  u.sed  to  create,  maintain,  access,  update,  and  protect  one  or  more 
data  bases"  (.^0:222). 


Some  advantages  of  this  type  of  system  include: 


1 .  It  offers  rapid  access  to  and  flexible  use  of  information.  A  DBMS  uses 
sophisticated  methods  of  organization  and  retrieval. 

2.  The  incidence  of  redundancy  (repetition)  is  limited  and  information  kept 
current.  This  is  critical,  because  there  is  a  direct  relationship  between 
the  efficiency  of  a  computer  program  and  its  ability  to  avoid  storing 
unnecessary  information  and  to  keep  the  information  it  does  store  up-to- 
date. 

3.  The  cost/benefit  ratio  is  good.  The  cost  of  setting  up  and  operating  a 
DBMS  is  low  compared  to  the  value  of  the  benefits  it  affords. 

4.  Storage  of  information  is  compact,  compared  to  paper  storage. 

5.  Mundane,  repetitive  tasks  such  as  searching  for  information  and 
preparing  reports  can  be  automated. 

6.  A  DBMS  imposes  an  organized  structure  that  would  be  difficult  to  attain 
manually.  Once  a  DBMS  has  been  established,  its  maintenance 
encourages  efficiency  in  office  procedures.  (31:8) 


These  benefits  are  not  without  their  corresponding  drawbacks.  Some  disadvantages 
of  using  Database  Management  Systems  are: 

1 .  Operation  and  programming  requires  skill  in  the  use  of  the  system  as  well 
as  a  knowledge  of  DBMS  concepts. 

2.  Because  information  is  stored  in  acomplex  way,  it  can  bedifficult  to  back 
up  or  reconstruct. 

3.  Information  is  centralized,  and  it  requires  maintenance.  Someone  must 
assume  responsibility  for  administering  the  DBMS. 

4.  As  the  power  and  features  of  the  DBMS  are  utilized  more  complex 
information  management  is  required ,  and  this  generates  new  administrative 
problems.  (31:8) 


Decision  Support  Systems  (DSSs).  There  are  many  variants  to  the  definition  of  a 
Decision  Support  System  offered  in  current  literature.  M.  J.  Ginzbergand  E.  A.  Stohr  offer 
one  that  seems  particularly  applicable.  Their  proposal  reads:  "a  DSS  is  a  computer-based 
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information  system  used  to  support  decision  making  activities  in  situations  where  it  is  not 
possible  or  not  desirable  to  have  an  automated  system  perform  the  entire  decision  process’  ’ 
(17:12). 

The  components  of  the  Decision  Support  System  are:  a)  the  database,  b)  the  database 
management  facilities,  c)  the  quantitative  modeling  component,  d)  the  report  generator,  and 
e)  the  human  interface  (10:75).  These  elements  combine  to  provide  the  user  with  the 
information  required  to  base  a  decision. 

The  key  characteristics  of  effective  DSS  are: 

1 .  Support  for  semi -structured  (underspecified  decisions) 

2.  Support  for  all  phases  of  decision  making  (intelligence,  design,  choice, 
implementation) 

3.  Combination  of  modeling  (analytic)  techniques  with  data  base  and  data 
presentation  techniques 

4.  Emphasis  on  ease  of  use  and  flexibility/adaptability  (compared  to 
execution  efficiency) 

5 .  An  interaction  with  transaction  processing  (EDP)  and  other  information 
systems,  such  as  MIS  and  office  systems  (30:300) 


Expert  Systems  lESs).  "An  Expert  System  captures  and  stores.  . .  knowledge,  such 
as  rules,  policies  and  logic,  in  a  knowledge  base  in  much  the  same  way  as  a  conventional 
computer  program  stores  numeric  information  in  a  database"  (3:25).  It  is  comprised  of 
the  following  components:  an  inference  mechanism,  a  knowledge  base,  a  database 
management  component,  a  report  generator,  and  finally  a  user  interface.  ( 10:65).  (Figure 
2-1) 


Following  IS  a  list  of  properties  .  .  common  to  many  expert  systems: 


Explicit  representation  of  domain  knowledge. 

A  general-purpose  inference  mechanism  providing  control. 

Provision  for  reasoning  with  uncertain  evidence  and  knowledge. 

Provision  of  justification,  explanation  and  other  run-time  user  support 
(8:7) 


expert  system 


USER  INTERFACE 

— Pror-pii'ig 
— Ecror  decking 


REPORT 

GENERATOR 

Format  and 
d  splay  results 


KNOWLEDGE  BASE 

If-Tnen 

rules 


DATABASE 

MANAGEMENT 

COMPONENT 

—Insert  data 
-Ed't 
—Update 
—Delete 


INFERENCE 

MECHANISM 

Given  certain 
conditions  or 
circumstances 
wtia;  'S  the 
probable  cause 
or  recommend 
course  of  action 


FIGURE  2-1  -  O  )Ml>ONI.NTS  1)1  AN  Exn.KT  SvsTiAt  (10:65) 


There  are  several  advantages  inherent  to  the  development  process  of  expert  systems. 
Frequently,  the  act  of  developing  an  expert  system  provides  the  first  documented  record 
of  the  knowledge  contained  in  an  area.  The  existence  of  such  a  system  provides  consistency 
that  is  usually  not  present  with  humans.  And,  knowledge  captured  in  these  systems  is 
available  to  a  larger  audience  than  a  finite  number  of  human  experts  (1:20-22). 


2-5 


However,  expert  systems  are  not  without  their  limitations,  “Currently  expert 
systems  can  address  only  very  narrow  areas  of  expertise  and  have  limited  capability  to 
encode  common  sense.  .  .  .  Expert  Systems  also  have  only  limited  capability  to  explain 


their  reasoning"  (3:45). 

Table  2-1  depicts  the  difference  between  Decision  Support  Systems  and  Expert 
Systems.  To  summarize  the  table,  the  focus  of  the  decision  support  system  is  to  aid  the 
manager  in  identifying  the  best  alternatives.  The  expert  system,  however,  seeks  to  find  the 
single  best  solution  to  a  problem.  Because  of  this  difference  between  the  systems,  the 
background  of  each  user  typically  is  different.  A  manager  typically  uses  a  decision  support 
system  to  identify  the  range  of  possible  solutions,  and  then  adapts  the  solutions  to  the  real 


TABLE  2-1 

Comparison  of  DSS  and  ES  (29:49) 


Decision  Support 
System 

Expert  System 

Paradigm 

Management 
decision  making 

Problem  Solving 

Goal  of  system 

Support  of  intuition 

"Complete"  solution 

Goal  type 

"Ill-specified" 

"Well-specified" 

User 

Manager 

Educated  layperson 

Factors  of  influence 

Not  predictable 

From  many  domains 

Predictable 

Restricted 

Representation 
problem  solving 

Sparse 

representation 

Dense  representation 

Control 

With  the  user 

With  the  system 

Techniques 

Tools  in  formalized 
subdomains 

Artificial  Intelligence 
Knowledge  represe. 
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world  problem.  The  user  of  an  expert  system  generally  has  little  background  knowledge 
of  the  problem  and  acts  on  the  single  answer  provided. 

Applicability.  The  literature  review  provided  the  following  key  characteristics  regarding 
each  system  considered. 

1 )  Data  Base  Management  System 

a)  Stores,  maintains  and  retrieves  data. 

b)  Presents  all  stored  data  whether  relevant  or  not. 

2)  Decision  Support  System 

a)  Excludes  information  irrelevant  to  the  question. 

b)  Supports  ill-defined  problem  analysis. 

3)  Expert  System 

a)  Provides  a  single  answer  to  an  inquiry. 

b)  Requires  highly  structured  problem  definition. 

The  vendor  selection  process  at  DESC  involves  more  than  the  storage  and  retrieval 
of  data  (the  focus  of  the  database  management  system).  The  information  requirements 
extend  beyond  simple  reporting  of  stored  information.  Vendor  pricing  information  is  the 
data  of  primary  interest.  This  information  however,  is  not  used  in  isolation.  To  be  useful, 
the  pricing  data  must  be  reviewed  with  vendor  performance  and  market  reasonableness  data. 
For  these  reasons,  an  approach  using  a  pure  database  management  system  ideology  is 
unsatisfactory. 

An  expert  system's  purpose  is  to  arrive  at  a  single  conclusion  given  a  well  defined 
set  of  constraints.  All  inputs  to  the  vendor  selection  process  are  not  yet  succinctly  defined. 
The  decision  prcKess  at  DESC  involves  a  synthesis  of  empirical  data  and  buyer  experience. 
Without  a  solid  understanding  of  how  all  the  inputs  interact,  making  a  successful  expert 
system  is  unlikely.  While  this  isa  worthwhile  project  for  future  research,  it  extends  beyond 
the  timeframe  available  for  this  developmental  effort.  Therefore,  the  expert  system 
approach  is  rejected. 
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The  decision  support  system  appears  to  be  able  to  satisfy  the  research  criteria.  It 
possesses  the  features  of  incorporating  data  file  structure  with  a  set  of  ‘intelligent’  rules, 
thereby  screening  the  data  presented  to  the  user. 

The  concept  of  DSS  requires  that  the  data  base(s)  and  these  modeling 
techniques  be  brought  together  in  an  interactive  way  to  enable  multiple 
alternatives  to  be  evaluated  and  to  ensure  that  the  best  decision  is  made. 

Helping  the  .  .  .  manager  through  the  decision-making  process  does 
not  mean  that  the  DSS  will  produce  THE  answer,  The  more  correct  focus 
is  to  interpret  the  DSS  result  as  a  suggestion.  The  [manager]  is  still  the 
decision-maker  and  needs  to  think  of  the  outputs  of  the  DSS  as  result  which 
should  be  considered  with  other  variables  .  .  ..(13:2) 

With  the  philosophy  of  a  decision  support  system  closely  paralleling  the  direction 
of  this  project,  an  examination  of  the  decision  support  system’s  components  is  in  order. 

Allen  and  Emmelhainz  identify  three  fundamental  elements  of  the  decision  support 
system  as:  the  dialog  subsystem,  the  data  base  subsystem,  and  the  models  subsystem 
(2:132). 

The  following  compares  the  characteristics  of  each  subsystem  with  the  problems 
identified  in  the  vendor  selection  process. 

The  dialog  subsystem  establishes  the  degree,  format,  and  method  of 
interface  with  the  user.  Many  DSS  experts  consider  this  the  most  important 
subsystem  since  the  power,  flexibility,  and  usability  characteristics  of  the 
entire  DSS  are  determined  by  the  dialog  subsystem.  The  two  components 
of  this  subsystem  are  the  communication  methods  (software)  and  the 
equipment  (terminals,  etc.).  Nearly  all  dialog  subsystems  include  interac¬ 
tive  terminals  as  the  interface  equipment  (2:3). 

For  the  prototype  to  communicate  with  the  buyers,  some  form  of  a  dialog  subsystem 
must  be  in  place.  The  proposed  method  capitalizes  on  the  versatility  of  the  personal 
computer  as  the  input/output  device. 
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The  data  base  subsystem  is  the  storehouse  of  knowledge  for  the  DSS . 

It  records  and  manipulates  data  from  both  internal  and  external  sources,  This 
subsystem  usually  has  the  capability  of  combining  data  from  a  number  of 
sources,  adding  or  deleting  data  quickly,  and  presenting  it  in  user- 
understandable  terms.  Most  data  base  subsystems  allow  for  interactive  input 
of  data.  The  output  of  the  data  from  the  data  base  subsystem  is  often  used 
as  input  to  the  models  subsystem  (2:3). 

’Combing  data  from  several  sources’  is  crucial  to  this  project.  The  prototype  will 
be  asked  to  track  data  maintained  in  several  different  data  files  and  present  only  the 
information  that  is  relevant  to  the  buyers  inquiry. 

The  models  subsystem  contains  the  analytical  technic  .es  used  to 
evaluate  data  and  to  determine  “Solutions.”  This  subsystem  catalogs  and 
maintains  a  wide  range  of  models  to  support  all  levels  and  functions  of  users. 

In  many  DSS,  the  models  subsystem  is  imbedded  in  the  information  (dialog) 
subsystem  to  allow  easy,  interactive  access  to  the  models  by  the  user  (2:3). 

In  the  approach  applied  by  this  research,  the  models  subsystem  is  perhaps  the  least 
autonomous  of  the  three  systems.  The  model  coding  lies  dispersed  throughout  the 
prototype.  Portions  of  the  model  function  in  tandem  with  the  data  base  manager.  Other 
functions  are  not  called  upon  until  the  screen  displays  are  presented  to  the  user.  The  model 
used  in  the  prototype  performs  both  analytical  (i.e.  performing  extended  price  calculations) 
and  discriminatory  (i.e.  screening  debarred  vendors  from  the  user)  manipulation  of  the  data. 

Through  the  data  review  and  discrimination  process,  the  system  should  provide  the 
user  with  only  the  data  relevant  to  the  decision  making  process,  and  inform  the  user  of  any 
peculiarities  existing  in  the  data  set.  Providing  the  user  with  ‘just  the  facts’  should  provide 
a  faster,  more  precise,  and  ultimately  superior  solution  than  is  obtainable  using  current 
methods. 


Synopsis.  This  review  examined  the  characteristics  of  three  types  of  automated  assistant 
systems.  Those  considered  were:  database  management  systems,  decision  support  systems. 


and  expert  systems.  The  method  displaying  the  most  promise  to  satisfy  the  needs  of  DESC 
is  the  decision  support  system. 


System  Verification 

Having  identified  the  basic  characteristics  the  system  requires,  attention  is  now 
turned  to  software  testing  for  the  system.  This  section  addresses  the  third  supporting 
question,  ‘Once  developed,  how  can  the  system  be  verified?’ 


Testing  vs  Debugging.  It  is  interesting  to  note  a  difference  exists  between  software  testing 
and  software  debugging.  ‘  The  purpose  of  testing  is  to  show  that  bugs  exist.  The  purpose 
of  debugging  is  to  find  the  error  or  misconception  that  led  to  the  program’s  failure  and  to 
define  the  program  changes  that  correct  the  error”  (6:5).  Beizer  lists  the  following 
differences  between  testing  and  debugging; 

1 .  Testing  starts  with  Icnown  conditions,  uses  predefined  procedures,  and 
has  predictable  outcomes.  Only  whether  or  not  the  program  passes  the 
test  is  unpredictable.  Debugging  starts  from  possibly  unknown  initial 
conditions,  and  the  end  cannot  be  predicted,  except  statistically. 

2.  Testing  can  and  should  be  designed  and  scheduled  beforehand.  The 
procedures  for,  and  duration  of,  debugging  cannot  be  so  constrained. 

3.  Testing  is  a  demonstration  of  error  or  apparent  correctness.  Debugging 
is  a  deductive  process. 

4  Testing  proves  a  programmer’s  failure.  Debugging  is  the  programmer's 
vindication. 

5.  Testing  should  strive  to  be  predictable,  dull,  constrained,  rigid,  and 
inhuman.  Debugging  demands  intuitive  leaps,  conjectures, 
experimentation,  intelligence,  and  freedom. 

6.  Testing .  to  a  large  extent,  can  be  designed  and  accomplished  in  ignorance 
of  the  design .  Debugging  i  s  impossible  without  detailed  design  knowledge. 


7.  Testing  can  be  done  by  an  outsider;  debugging  must  be  done  by  an 
insider. 

8.  While  it  is  possible  to  establish  theoretical  limits  to  what  testing  can  and 
cannot  do,  debugging,  so  far,  has  not  been  amenable  to  theoretical 
treatment.  (6:5-6) 

As  alluded  to,  debugging  is  a  very  inexact  art  performed  by  the  program r.:er. 
Testing,  on  the  other  hand,  is  more  of  a  science,  and  may  be  performed  by  anyone. 

Testing  ’There  are  two  steps  in  functional  testing.  The  first  involves  the  identification 
of  the  functions  that  are  implanted  in  a  program.  The  second  involves  t  .  j  selection  of  test 
data  that  can  be  used  to  check  that  the  program  implements  the  functions  correctly” 
(22:281). 

Program  Functions.  One  method  for  verification  involves  functional  analysis  of  the 
software.  But  how  does  one  identify  a  function?  Howden  describes  a  function  with  the 
following:  ’  "The  most  important  feature  of  a  function  is  that  it  can  be  independently  tested. 
The  input  and  output  domains  for  each  of  the  functions .  .  .  can  be  completely  specified” 
(23:282).  This  brings  to  mind  the  concept  of  modular  programming,  the  process  of 
designing  the  software  in  discrete  but  cooperative  units.  “To  avoid  .  .  .  difficulties  e’  cry 
large  program  should  be  divided  into  a  series  of  modules  or  procedures  (subroutines  and 
functions)  so  designed  that  each  does  a  clearly  defined  task,  is  a  logical  part  of  the  original 
problem,  and  so  far  as  possible  uses  only  its  own,  locally  defined  variable”  (27:65).  Each 
module  in  the  program  has  its  own  unique  input/output  criteria  and  can  be  developed  apart 
from  the  rest  of  the  system. 

Test  Data. 

Identification.  The  test  data  comprises  the  other  major  element  of  the  testing 
process.  One  might  believe  if  a  thorough  test  is  to  be  conducted,  it  would  be  necessary  to 


submit  data  elements  for  all  possible  inputs.  As  J.  C.  Huang  points  out  in  his  paper,  this 
is  an  impossible  quest. 

Suppose  the  program  to  be  tested  has  two  input  variables  and  one 
output  variable  as  depicted  below; 


input  (XY) 


PROGRAM 
to  be  tested 


output  (Z) 


If,  for  an  assignment  of  values  to  the  input  variables  X  and  Y,  the 
output  variable  Z  will  assume  a  correct  value  upon  execution  of  the  program , 
then  we  can  assert  that  the  program  is  correct  for  this  particular  test  case. 
And  if  we  can  test  the  program  for  all  possible  assignments  to  X and  Y,  then 
we  will  be  able  to  determine  its  correctness.  The  difficulty  here  is  that,  even 
for  a  program  with  only  two  input  variables,  the  number  of  possible 
assignments  will  be  prohibitively  large.  To  see  why  this  is  so,  let  us  assume 
that  X  and  Y  are  integer  variables.  Furthermore,  let  us  assume  that  the 
program  is  to  be  run  on  a  computer  with  32-bit  registers.  There  are  2^-  X 
232  _  2*^  possible  assignments  to  the  input  pair  (X,  Y).  Now  suppose  this 
program  is  relatively  small,  and  on  the  average  it  takes  one  milli-second  to 
execute  the  program  once.  Then  it  will  take  more  than  50  billion  years  for 
us  to  complete  the  test!  (24:289) 


There  is  an  alternative  to  absolute  testing.  "The  two  most  important  kinds  of 
functional  test  data  are  extremal  values  and  special  values.  Extremal  values  lie  on  the 
“edges"  or  "boundaries"  of  sets  of  data.  Special  values  have  special  algebraic  or 
computational  properties"  (22:184).  These  two  data  types  may  be  defined  further  by  the 
following; 


The  identification  of  extremal  values  for  unstructured  numeric 
variables  is  relatively  simple.  If  the  domain  of  the  variables  is  an  interval 
of  the  form  [a,  h],  then  a  and  h  are  the  extremal  values.  If  the  variable  is 
of  type  integer,  then  a  +  1  and  b  -  1  can  also  be  considered  extremal.  Each 
element  of  a  small  finite  set  of  elements  can  be  thought  of  as  an  extremal 
value.  If  a  numeric  variable  is  used  in  a  function  that  carries  out  arithmetic 
computations,  then  the  special  values  for  the  variable  include  zero.  ±e  (for 
(’small)and  ±E  (forflarge).  Similar  rulescan  be  used  to  identify  important 
test  data  values  for  non-numeric,  unstructured  variables  (23:284). 


Application.  With  the  tools  in  hand,  attention  is  turned  to  their  application.  To  apply  the 
variables,  we  look  not  at  the  program  modules,  but  analyze  the  program  logic,  seeking  to 
describe  the  program  paths.  A  program  path  is  “the  sequence  of  instructions  which  is 
performed  for  a  given  set  of  inputs.  If  this  works  correctly,  then  all  other  sets  of  inputs  which 
cause  the  program  to  follow  the  same  path  also  yield  the  correct  result”  (27:88). 

Path  testing  is  a  structural  test  technique  that  focuses  on  control 
structures  rather  than  processing.  A  process  has  one  entry  and  one  exit.  It 
performs  one  or  more  operations  on  data.  It  can  consist  of  one  instruction 
or  a  long  sequence  of  instructions  unbroken  by  program  ’■ranches  or 
junctions.  From  the  point  of  view  of  path  testing,  a  one-instructioi.  process 
and  a  1000-instruction  process  are  equivalent  -  they  are  both  processes 
(6:38). 

The  application  of  these  concepts  as  described  below  will  be  useful: 

It  is  convenient  to  abstract  the  notion  of  path  further  and  to  deal  with 
a  graph  representation  of  a  program.  Junctions  and  decisions  are  replaced 
with  the  more  abstract  and  simpler  notion  of  node.  A  node  is  any  point  in 
the  program  where  the  control  flow  either  merges  or  diverges  or  both .  Nodes 
are  joined  by  links.  Processes,  as  defined  above,  are  examples  of  links. 
However,  a  link  may  do  no  actual  processing.  For  example,  a  conditional 
branch  instruction  consists  of  a  node  (the  decision  instruction)  and  two  links 
(the  flowchart  lines  that  depict  the  branch  alternatives.)  The  graph 
representation  is  convenient  because  it  depicts  only  labels  or  addresses  and 
the  path  segments  that  join  them  (6:38). 


These  paths  may  not  necessarily  correspond  to  the  developmental  program  modules 
defined  in  the  above  section.  They  may  be  a  subset  of,  or  an  amalgamation  of  those  modules. 
In  most  cases,  the  result  is  a  simpler,  easier  to  comprehend  representation  of  the 
programming  logic  (6:38). 


Approach.  To  verify  the  prototype,  path  identification  and  testing  is  a  viable  method.  The 
verification  process  can  be  simplified  through  the  use  of  modular  software  design 
techniques.  As  such,  a  modular  development  approach  is  adopted.  Under  this  concept. 
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prototype  testing  is  accomplished  by  first  identifying  the  program  paths.  Once  the  paths 
are  defined,  they  are  examined  to  identify  their  specific  extremal  and  special  values,  as  well 
as  the  associated  results.  After  software  analysis  identifying  pertinent  inputs  and  expected 
outputs  is  completed,  system  performance  can  be  tested  using  this  anticipatory  information 
as  judgmental  criteria. 

Conclusions 

This  research  conducted  in  support  of  the  chapter  focused  on  three  questions.  The 
first  being,  'What  type  of  computer  assistant  systems  can  satisfy  DESC’s  requirement?' 
Three  systems  were  examined,  each  with  its  own  strengths.  Those  systems  examined  were: 
data  base  management  system,  decision  support  systems,  and  expert  systems.  It  is  believed 
that  a  decision  support  system  can  best  fulfill  the  DESC’s  requirements.  The-attributes  of 
each  system  was  reviewed  as  required  by  the  second  question,  ‘What  are  the  strengths  and 
weaknesses  of  the  systems  under  consideration?’  A  decision  support  system  was  selected 
based  on  the  constraints  imposed  by  the  problem.  It  was  nether  required  nor  desired  by 
DESC  to  have  the  system  provide  ‘a’  solution.  Buyer  analysis  of  the  decision  criteria  will 
still  be  accomplished.  As  such,  simplification  of  the  data  reviewed  by  the  buyers  was 
sought.  The  final  question,  ‘Once  developed,  how  can  the  system  be  verified?’,  was 
addressed  next.  Software  verification  will  be  accomplished  through  extremal  and  special 
variable  application  through  program  paths.  The  details  of  these  procedures  can  be  found 
in  the  following  chapters. 
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III.  Methodology 


Overview 

This  chapter  describes  the  approach  used  to  identify  the  bounds  of  the  research 
problem,  and  describes  the  development  and  evaluation  processes  that  will  follow.  Problem 
identification  was  achieved  by  conducting  personal  interviews  at  DESC  with  the  manage¬ 
ment  and  those  workers  directly  affected.  After  prototypie  development  was  completed,  an 
experiment  was  conducted  to  test  the  effectiveness  of  the  resulting  design. 

Problem  Identification 


Methodology.  The  efforts  of  this  development  will  be  integrated  into  an  encompassing 
program  (VASPP).  Therefore,  it  was  first  necessary  to  become  familiar  with  the  larger 
system  and  how  the  development  efforts  of  this  research  will  integrate  into  it.  This  was 
completed  through  a  series  of  interviews  with  the  DESC.management.  “This  is  the  stage 
when  knowing  who,  what,  where,  when,  how  and  how  much  is  important.  The  most 
effective  means  of  obtaining  this  information  is  by  interviewing.  One  of  the  advantages  of 
interviewing  is;  "in  the  depth  and  detail  of  information  that  can  be  secured”’  (15:60). 

An  introductory  meeting  was  held  with  the  Chief,  PPS  (Procurement  and  Policy), 
to  gain  a  better  understanding  of  the  VASPP  concept  and  DESC's  expected  benefits  from 
this  development  effort  (9).  Through  these  interviews,  information  was  gathered 
concerning  the  scope  of  the  VASPP  project.  As  a  result  of  information  extracted  from  this 
meeting.  Figure  3-1  was  constructed  as  a  simplistic,  visual  representation  of  VASPP.  This 
was  presented  to  COL  Hewett  (DESC-P)  and  his  staff  (18).  The  concepts  portrayed  by  this 
model  were  accepted  by  DESC  with  minor  changes. 

The  VASPP  system,  as  envisioned,  will  receive  inputs  concerning  bid  and  pricing 
information  from  the  vendor.  The  inputs  will  enter  the  system  through  an  electronic  or 
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telecommunication  medium.  These  inputs  will  be  checked  for  validity  and  integrity  by  the 
translator  module.  After  passing  validity  checks,  the  information  is  formatted  for  inclusion 
into  the  central  vendor  pricing  database.  The  buyers  at  DESC  may  then  interrogate  the 
database  through  the  decision  support  system  to  cull  out  the  vendors  appropriate  for  a  given 
request. 
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Decision  Criteria.  The  VASPP  concept  is  a  composite  of  several  operations  that  must 
interact  with  one  another.  The  development  of  the  entire  VASPP  system  extends  beyond 
the  scope  of  a  single  thesis.  Therefore,  the  author  chose  to  explore  a  single  aspect  of  the 
program.  Focus  was  placed  on  the  end  user  requirements  of  the  system.  By  having  the 


destination  clearly  identified,  it  will  be  easier  to  orient  the  development  efforts  of  future 
system  modules  in  the  proper  direction. 

Examination  of  the  vendor  selection  and  award  processes  was  the  first  step  in 
identifying  the  requirements  of  this  system.  This  was  accomplished  through  personal 
interviews  with  the  buyers  and  management  at  DESC  (20).  The  details  of  those  interviews 
can  be  found  in  Chapter  IV. 

Once  the  concept  of  the  award  process  was  understood,  the  next  area  explored  was 
the  identification  of  the  data  used  in  the  buyer’s  decision  process.  This  information  sprang 
from  several  different  sources.  The  identification  of  those  sources  was  accomplished 
through  interviews  with  Mr.  M.  Corelis  and  Mr.  D.  Dickman  (9). 

Several  data  elements  were  identified  relative  to  the  decision  process.  They  include 
the  following  components: 

a)  most  economical  quantity  pricing, 

b)  existence  of  DESC-identified  quality  vendors, 

c)  existence  and  degree  of  DESC-identified  problem  vendors, 

d)  existence  and  degree  of  customer  compiaints  toward  the  vendors,  and: 

e)  existence  of  excessive  overdue  orders  from  the  vendor. 

Also,  consideration  must  be  given  to  other  information  where  guidance  is  less 
formalized.  These  data,  alone,  cannot  be  used  as  the  sole  criteria  from  which  a  decision 
is  made.  However,  they  can  influence  the  final  decision  when  viewed  with  other  factors 
previously  mentioned.  These  elements  are; 

a)  size  of  vendor  business; 

b)  ownership  of  vendor  business;  and, 

c)  freedom  of  the  buyer  to  contract  beyond  the  requested  quantity. 


3-3 


Having  completed  the  process  of  identifying  the  decision  criteria,  the  next  step  was 
to  learn  how  to  apply  that  criteria.  This  was  achieved  through  working  directly  with  the 
buyers  on  the  floor.  First,  the  vendor  selection  process  was  observed  by  the  researcher. 
To  verify  the  process  was  understood,  the  researcher  processed  several  purchase  requests 
under  the  scrutiny  of  the  buyer.  The  buyer  observed  the  researcher’s  actions  to  assure 
consistency  and  completeness  with  the  established  procedures. 

Proposal  Development 

Methodology.  Figure  3-2  outlines  the  process  used  in  identifying  the  characteristics  of  the 
problem  and  its  transformation  into  the  Decision  Support  System. 


DEVELOPMENT  PROCESS 

Examine  Buying  Process 
Determine  Inputs  and  Outputs 
Validate  Information  Requirements 
Develop  Logic  Flow 
Produce  Program  Code 
Demonstrate  the  Prototype 

FIGURE  3-2  -  SiKr<  n  ki  hi  Di  vi  i  (Cmi m  Pkix  i.ss 
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As  stated  earlier,  the  first  task  in  the  development  process  was  to  gain  an 
understanding  of  the  current  buying  procedures.  Once  understanding  of  the  procurement 
process  was  gained,  the  input  and  output  requirements  of  the  buyer  were  analyzed. 
Accomplishment  of  the  above  was  achieved  through,  and  confirmed  by,  personal  interviews 
with  the  management  and  buyers  at  DESC. 

Now,  being  knowledgeable  in  the  fundamental  process  used  in  small  contract 
procurement  process,  a  detailed  logic  flow  diagram  was  developed  to  capture  the  concepts 
needed  for  software  development.  (This  flowchart  is  detailed  in  Chapter  IV.)  In  designing 
the  prototype,  the  researcher’s  goal  was  to  incorporate  a  structure  that  could  be  expanded 
to  manage  the  procurement  of  thousands  of  items.  High  consideration  was  given  to  system 
design  to  lessen  the  impact  of  data  maintenance  overhead.  As  a  result,  the  identification, 
transformation  and  utilization  of  data  already  collected  and  maintained  at  DESC,  was  given 
the  utmost  consideration. 

After  essential  core  elements  of  the  prototype  system  were  coded,  it  was  examined 
by  DESC  for  consistency  with  their  conceptual  requirements  (19). 

The  DSS.  Figure  3-3  depicts  the  informational  flow  to/ from  the  user  and  supporting 
data  bases,  through  the  developed  DSS.  It  is  comprised  of  three  sections,  the  dialog,  the 
database,  and  the  model  subsystems. 

A  r^’quest  for  information  is  entered  by  the  user  into  the  input/output  subsystem 
(dialog  subsystem).  The  system  compares  the  request  against  the  data  stored  in  the  price 
data  file.  Bidding  vendors  are  examined  for  past  performance  information  by  the  database 
subsystem.  The  model  subsystem  reviews  the  results  obtained  thus  far.  It  removes  any 
extraneous  data  and  alerts  the  buyer  to  unusual  circumstances.  The  filtered  information  is 
passed  onto  the  input/output  subsystem,  where  it  is  displayed  on  the  terminal  for  user 
review. 
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Having  the  potential  to  be  used  by  many  users,  it  could  not  be  assumed  all  users 
would  have  a  high  degree  of  computer  experience.  Thus,  an  effort  was  made  to  keep  the 
dialog  system  as  modest  and  direct  as  viable. 


•  V 


DSS 


FIGURE  3-3  lNK)R.\t/\ni)N  Flow 

An  effort  was  made  to  reduce  the  space  required  for  additional  data  storage  and 
maintenance  tasks  for  the  data  processing  center  at  DESC.  The  database  subsystem  was 
designed  to  maximize  the  use  of  file  information  currently  in  existence  on  line.  For 
efficiency  of  data  inferrngafinn  the  database  encompasses  several  small  data  files 
containing  related  fields.  This  approach,  as  opposed  to  the  use  of  a  few  large,  encompassing 
files,  enhances  the  system  analysis  of  the  data,  enabling  faster  data  searches  and  retrieval. 

To  provide  the  management  at  DESC  the  ability  to  tailor  the  prompts  provided  to 
the  buyer,  a  model  subsystem  was  incorporated.  Selected  outputs  of  the  system  can  be 
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changed  based  on  the  contents  of  this  user  model,  thereby  influencing  the  final  award. 
Criteria  for  selecting  which  outputs  to  modify  were  based  on  the  DPAC’s  information 
system  now  in  use  at  DESC.  DPAC  is  a  computer  system  that  is  used  for  other  type  of  vendor 
awards. 

The  model  subsystem  is  a  separate  file  that  contains  configuration  parameters 
controlled  by  the  system  manager.  These  parameters  influence  the  range  of  ‘acceptable’ 
bids  and  the  presentation  of  informational  prompts  to  the  user. 

Verification 

Knowledge  gained  through  the  literature  review  was  applied  in  the  verification 
process.  Logic  diagrams  were  constructed  identifying  the  activities  the  prototype  was 
required  to  perform .  Independent  tasks  were  isolated  to  assist  in  modular  development.  The 
operation  of  the  DSS  was  verified  after  the  addition  of  each  software  function.  After 
completing  the  development  process,  the  prototype  was  tested  to  assure  inter-module 
compatibility.  Using  the  technique  of  flow  path  identification,  the  model  and  data  files  were 
modified  as  required  and  the  system  tested  to  insure  all  paths  were  functioning.  Any 
unexpected  results  were  analyzed  and  if  appropriate,  corrected. 

Validation 

The  goal  of  this  research  project  is  to  design  and  develop  an  effective  automated 
system  to  enhance  the  contract  award  process  at  DESC.  This  system  must  be  easy  to  use 
and  provide  the  correct  information,  enabling  the  buyer  to  select  an  appropriate  vendor  for 
each  purchase  request.  To  determine  if  the  developed  system  meets  these  criteria,  a  three 
step  testing  process  was  carried  out. 

Phase  1. 

Overview.  A  panel  compared  the  information  provided  by  the  automated  system 
against  that  provided  by  the  current  prcKess. 
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Procedure.  A  panel  of  ’experts’  was  formed  to  rate  the  system.  This  panel  consisted 


of  the  following  individuals: 

1)  An  experienced  buyer.  This  member  will  be  knowledgeable  with  the 
5905  award  criteria  and  be  selected  by  the  ‘5905’  supervisor. 

2)  An  experienced  contracting  officer.  This  person  should  be  responsible 
for  insuring  the  daily  accuracy  of  the  5905  contract  awards.  He/she  will 
be  nominated  from  management  overseeing  the  buyer  floor. 

The  panel  selected  thirty  purchase  requests  for  MilSpec  55 1 82  from  the  5905  stock 
class  input  stream.  (MilSpec  55 1 82  was  the  data  subset  available  to  the  researcher  for  testing 
purposes.)  The  prototype  testing  was  accomplished  through  the  following  process. 

A  purchase  request  was  arbitrarily  selected  from  the  sample  set.  It  was  processed 
using  the  existing  manual  method  for  vendor  selection.  Special  attention  was  given  to  the 
specified  data  files  interrogated  and  the  information  provided  by  those  files.  These  data  were 
recorded  on  a  form  attached  to  the  purchase  request  (Figure  3-4). 

A  standard  abstract,  DESC  Form  701 ,  was  also  prepared  to  record  all  vendor  pricing 
information  for  the  item  identified  on  the  purchase  request  (Figure  3-5). 

After  these  steps,  the  panel  members  determined  which  vendor  should  receive  the 
contract  award.  If  it  was  unclear  which  vendor  should  receive  the  award,  those  under 
consideration  were  recorded. 

Having  completed  the  manual  process,  the  same  purchase  request  was  entered  into 
the  prototype  system  by  the  panel.  The  panel  recorded  any  deviations  or  omissions  of  the 
resulting  information  provided  by  the  system.  This  information  was  placed  on  the  form 
identified  in  Figure  3-4  as  well.  Using  the  information  provided  by  the  automated  system, 
the  panel  again  determined  which  vendor  was  most  qualified  to  receive  the  contract  award. 
The  selected  vendor  (or  vendors)  were  recorded  on  the  same  form. 

The  vendor  selected,  the  quantity  ordered,  and  the  total  contract  value  obtained  from 
the  manual  system  was  compared  to  that  from  the  automated  system.  The  panel  documented 
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any  deviations  between  the  systems.  "T^  ey  then  determined  which  system  provided  the  more 
appropriate  answer,  or,  documented  me  existence  of  equally  correct  vendor  selections. 

This  process  was  repeated  for  the  remaining  twenty-nine  purchase  requests.  Upon 
conclusion,  the  researcher  totaled  the  number  of  times  each  of  the  systems  provided  the 
superior  answer  and  the  number  of  times  the  two  systems  resulted  in  equivalent  answers. 
A  sign  Test  was  used  to  analyze  the  results.  Sign  Test  was  chosen  because.  .  . 

■'The  Sign  Test  isa  nonparametric  alternative  to  the  Paired  T  Test. 

It  requires  virtually  no  assumptions  about  the  paired  samples  other  than  that 
they  are  random  and  independent.  On  the  negative  side,  it  is  not  as  powerful 
as  the  Paired  T  Test  or  the  Wdcoxon  Signed  Rank  Test.  It  is  especially 
useful  for  situations  where  quantitative  measures  are  difficult  to  obtain,  but 
where  a  member  of  the  pair  can  be  judged  ‘greater  than'  or  ‘less  than’  the 
other  member  of  the  pair  (4:207). 

The  panel  members  from  DESC  were  asked  to  provide  a  narrative  of  their  comments 
regarding  the  automated  system  performance  and  effectiveness  compared  to  the  manual 
tysteiH,  This  was  accomplished  Oii  the  form  depicted  in  Figure  3-6. 

This  completes  the  first  phase  of  the  validation  process.  By  analyzing  the  data  that 
this  phase  generates,  a  determination  was  made  regarding  whether;  1 )  the  system  presented 
the  correct  information  to  the  buyer  for  an  award  decision;  and  2)  the  system  performed 
in  a  manner  consistent  with  the  expectations  of  DESC.’ 

Because  of  the  importance  of  the  decisions  this  system  will  influence,  a  high 
degree  cf  confidence  in  the  system  must  exist.  Accordingly,  the  minimum  acceptable  level 
of  accuracy  for  the  initial  prototype  was  set  (somewhat  arbitrarily)  at  ninety  percent 
confidence.  If  this  lesel  of  certainty  cannot  be  met,  the  validity  of  the  succeeding  phases 
would  be  questionable. 

The  second  criteria  that  must  be  met  before  advancing  to  the  nex*  phase  of  testing 
is  the  panel's  expectations  in  the  system.  If  the  system  fails  to  meet  the  panel'sexpectations. 


or  if  the  panel  believes  the  system  fails  to  perform  within  acceptable  standards,  they  may 
elect  to  cancel  further  testing. 

PANEL 

QUESTIONNAIRE 


Now  that  you've  had  a  chance  to  work  with  the  Amomated  Vendor  Selection  System, 
please  take  a  few  minutes  to  answer  the  following  questions  regarding  the  system’s  performance. 

Describe  any  problems  you  incurred  while  using  the  system. 

What  information  presented  by  the  syMcm.  if  any.  is  irrelevant  to  the  award  selection  procea? 


What  other  infortnatioo  should  the  system  provide  to  aid  in  the  award  process? 


Do  you  have  any  suggeatiuns  fur  future  enhancemenhi  to  this  system? 


Do  yon  have  any  other  comments  or  .suggestions  regarding  the  design  or  usefulness  of  this  .system? 

As  presented  today,  dues  the  system  aaswt  the  buyer  in  the  vendor  selection  process? 

FIGURE  .^-6  --  P\Ni  i  OrisnnwMHi 
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Phase  II. 


Overview.  A  panel  of  eight  buyers  processed  the  thirty  purchase  requests  in  the 
sample  set  using  a  combination  of  the  manual  and  the  automated  systems.  The  manual  run 
was  compared  to  the  automated  run  with  respect  to  processing  time.  The  vendors  selected 
using  the  automated  run  for  each  purchase  request  were  compared  to  those  selected  by  the 
’expert’  panel,  to  determine  whether  the  buyers  arrived  at  the  correct  answer. 

An  Analysis  of  Variance  ( ANOVA)  Test  was  used  wherever  appropriate  to  compare 
samples.  A  randomized  block  design  was  used  to  analyze  the  data.  “.  .  .the  randomized 
block  design  utilizes  experimental  units  that  are  matched  sets,  assigning  one  from  each  set 
to  each  treatment”  (26:878). 

Procedure.  A  pool  of  eight  buyers  was  formed  from  the  buyer  floor.  These  buyers 
were  to  have  experience  in  the  5905  stock  class  items.  The  software  was  loaded  on  the  eight 
personnel  computers  belonging  to  the  buyers.  Eight  copies  of  each  purchase  request  in  the 
test  set  was  produced,  each  with  a  blank  results  form  attached. 

When  this  phase  of  the  testing  begins,  four  of  the  buyers  were  given  half  of  the 
purchase  requests  (fifteen)  to  process  manually.  The  other  buyers  were  given  the  remaining 
requests  to  process  on  the  automated  system  The  buyer  noted  the  time  processing  of  that 
request  began  on  the  form  attached  to  each  request  (Figure  3-7).  Once  a  vendor  was  selected, 
the  buyer  recorded  the  chosen  vendor,  quantity  ordered,  and  total  price  of  the  award.  After 
completion,  the  buyer  recorded  the  current  time,  and  indicated  if  they  experienced  any 
external  delays  (i.e.,  phone  calls)  while  processing  the  transaction. 

This  process  was  repeated  until  all  fifteen  (half  of  thecomplete  set)  purchase  requests 
were  completed.  After  completion,  the  buyer  returned  the  purchase  requests  to  the 
researcher  and  received  the  remaining  fifteen  requests  for  processing.  If  the  buyer  used  the 
manual  system  to  process  the  first  set.  he/she  processed  the  second  set  using  the  automated 
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BUYER 

SELECTION 


FIGURE  3-7  -  BrvhR  Sr,i.i:rTi()N  Form 


system.  Conversely,  if  the  first  set  was  processed  using  the  automated  system,  he/she 
processed  the  second  set  manually.  After  the  buyers  complete  both  manual  and  automated 
processing  phases,  they  were  asked  to  complete  a  system  evaluation  form  (Figure  3-8).  This 
also  was  returned  to  the  panel  upon  completion. 

The  times  required  to  process  the  purchase  requests  were  summed  for  both  the 
manual  and  the  automated  .sets.  Any  purchase  request  that  showed  a  delay  in  processing 
occurred  will  not  be  included  in  the  totals.  The  average  processing  time  of  the  remaining 
requests  will  then  be  calculated  for  each  of  the  two  methods. 

Using  a  con,solidation  form  (Figure  3-9),  the  researcher  recorded  the  buyer's 
selection  for  each  purchase  request  processed  using  the  automated  system.  Also,  it  was 
noted  whether  the  buyer  arrived  at  the  same  award  decision  as  the  panel.  To  qualify  as  a 
match,  the  vendor,  quantity  and  price  must  agree.  If  these  three  criteria  did  not  match  the 


,M4 


FIGl'RE  3-8  -  Brvi  K  Qrt.snoNNAiKi. 


panel’s,  the  consolidation  form  was  marked  accordingly.  Those  purchase  requests  that 
deviated,  were  reviewed  by  the  panel.  If  the  panel  determined  the  buyer  (though  not  in 
agreement  with  their  first  choice)  has  made  a  reasonable  alternative  selection,  then  the 
respon.se  form  was  so  noted. 
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Once  all  purchase  requests  were  reviewed  from  all  buyers,  the  number  of  matching 
transactions  were  summed  with  the  number  of  reasonable  transactions.  The  result  was 
compared  to  the  number  of  discrepancies  minus  the  number  of  reasonable  transactions.  A 
reasonable  transaction  is  defined  as,  ‘an  award  selection,  differing  from  that  agreed  by  the 
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panel  as  ‘best’ ,  in  vendor,  quantity,  and/or  price;  but  still  satisfies  the  intent  of  the  purchase 
request  without  an  increase  in  unit  cost’. 

The  narratives  collected  from  the  buyers  after  the  test  were  reviewed  and  trends 
documented  in  the  final  report. 

Phase  III. 

Overview.  Phase  III  was  similar  to  Phase  II.  The  difference  being  the  eight  buyers 
performing  the  testing  did  not  routinely  work  with  5905  products,  and  they  processed  the 
requests  using  only  the  automated  system. 

Procedure.  As  before,  the  new  group  of  buyers  was  given  a  set  of  purchase  requests 
with  a  form  to  record  the  results  attached  to  each.  This  time  however,  they  were  given  only 
a  complete  set  of  fifteen  purchase  requests.  Each  request  was  processed  using  the  automated 
system,  and  the  results  recorded  on  the  attached  form.  When  the  set  of  requests  was 
completed,  the  average  time  to  process  the  requests  was  calculated,  and  the  award 
information  compared  to  the  panel’s  selections.  The  percentage  of  reasonable  responses 
was  compared  to  the  results  of  the  first  buyer  group. 

The  error  rate  and  average  ti  me  to  process  of  Phase  1 1  was  compared  to  those  of  Phase 
III,  looking  fora  significant  difference  in  test  results.  Such  a  difference  may  suggest  a  lack 
of  objectivity  in  awarding  contracts  brought  to  the  evaluation  by  the  buyers  from  the  5905 
group. 

For  example,  by  working  with  the  same  vendors  over  an  extended  fieriod  of  time, 
a  buyer  could  ‘know’  certain  traits  of  the  vendors.  Perhaps  one  vendor  always  quotes  a  lower 
price  than  another  vendor,  thus  the  buyer  may  improperly  make  the  award  decision  without 
examining  all  information  on  file.  Another  example  of  bias  that  could  develop  as  a  result 
of  prior  knowledge  is  described  as  follows.  A  vendor  has  been  historically  poor  in  meeting 
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scheduled  delivery  dates.  The  vendor  finally  identifies  the  cause  for  the  poor  performance 
and  corrects  the  situation.  The  problem  vendor  files  maintained  at  DESC  are  been  updated 
reflecting  this  change  in  p)erformance.  However,  the  buyer,  aware  of  the  past  problems, 
awards  to  another  vendor  quoting  a  higher  price.  In  this  situation,  the  award  was  made 
without  proper  justification. 

Conclusions. 

Chapter  III  introduces  the  methodology  followed  in  the  research  and  development 
of  this  project.  Specifically,  it  describes  the  method  of  development  for  the  Decision 
Support  System  and  the  approach  used  for  testing  its  utility.  Chapters  IV  and  V  contain 
the  details  regarding  the  verification  and  validation  of  the  results  of  this  effort. 


IV.  Development 


Overview 

This  chapter  recounts  the  design  and  verification  process  used  in  the  prototype 
development  process.  A  multi-step  development  process  was  used  to  arrive  at  the  ‘final’ 
system  design.  Those  steps  consisted  of:  user  interviews,  paper  prototype  development, 
initial  prototype  development  and  full  prototype  development.  To  insure  the  prototype 
would  perform  as  intended,  it  was  subjected  to  coding  verification  prior  to  validation  at 
DESC. 

The  reader  should  be  alerted  to  the  following  before  proceeding.  It  is  the 
researcher's  belief  that  software  development  is  as  much  art  as  it  is  science.  The 
development  process  detailed  in  the  following  pages  includes  techniques  developed  and 
refined  by  the  researcher  through  several  years  of  personal  programming  and  computer 
related  experience. 

It  is  not  the  intent  of  this  project  to  identify  or  suggest  ‘the’  proper  method  for 
software  development.  The  intent  is  to  document  a  successful  transformation  of  user 
requirements  into  an  effective  system.  The  results  obtained  from  validation  will  determine 
if  this  effort  was  successful. 

Investigative  Efforts 

User  Interview  Process.  To  identify  the  expectations  developed  for  the  completed 
prototype,  several  interviews  were  conducted  with  the  personnel  at  DESC.  Meetings  with 
DESC-P  and  other  management  level  personnel  were  useful  in  identifying  their  desires  for 
the  system.  Perhaps  the  most  important  outcome  from  these  meetings  was  an  understanding 
of  VASPP  and  the  relationship  this  development  effort  with  it.  (The  VASPP  concept  was 
discussed  in  an  earlier  chapter  and  will  not  be  repeated  here.) 
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Once  comfortable  with  management's  views  regarding  the  VASSP  program, 
attention  was  directed  to  the  buyers'  needs  of  the  system.  Before  a  successful  system  could 
be  designed,  the  buyers  process  for  vendor  selection  had  to  be  understood.  Again,  the 
interview  technique  was  used  to  identify  these  requirements.  Information  was  obtained  by 
talking  with  several  buyers  and  observing  the  vendor  selection  process.  The  researcher 
obtained  further  insight  by  actually  performing  the  mechanics  of  the  vendor  selection 
process.  The  buyers  provided  ‘real  world’  purchase  requests  and  in-tum  guided  the 
researcher  through  the  steps  necessary  to  arrive  at  an  award  decision.  This  exercise  assisted 
in  clarifying  the  buyers  data  requirements  and  its  useful  presentation. 

Results.  Through  this  series  of  interviews  and  exercises,  a  better  understanding  of  the 
vendor  selection  process  was  obtained,  and,  of  how  these  efforts  would  later  merge  with 
a  larger  system.  The  following  items  infuenced  the  prototype  development  efforts. 

Inputs.  Two  pieces  of  information  are  required  to  identify  the  pnce  offered  by  a 
vendor  for  a  specific  product.  The  first  is  the  ‘Type  number’.  The  second  is  the  quantity 
requested.  With  the  Type  number,  the  buyer  can  consult  the  vendor  price  list  to  identify 
if,  one,  a  particular  vendor  offers  the  product  for  sale,  and  two,  if  it  is  for  sale,  the  pnce 
per  unit  for  a  given  quantity.  The  buyer  can  next  compare  the  quantity  requested  with  the 
quantity  price  breaks  offered  to  obtain  the  best  value  for  the  customer. 

It  should  be  noted,  the  Type  number  identifies  a  specific  component,  the  price  lists 
however,  are  ‘grouped’.  A  range  of  similar  products  carries  the  same  pricing  information. 
It  is  the  product  grouping  that  the  vendors  must  identify  in  their  price  lists.  As  a  result,  the 
buyer  looks  not  for  a  specific  Type  number  in  the  price  lists,  but  must  identify  the  proper 
price  group. 

A  third  piece  of  information  isalso  required  before  making  the  final  award  decision. 
‘Set- A -Side’  is  a  term  DESC  uses  to  show  only  small  businesses  will  be  considered  to  receive 
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the  award.  As  a  result,  vendors  carrying  Marge  vendor’  status  are  ineligible  for  selection 
consideration. 

Outputs.  A  series  of  screens  was  designed  to  provide  the  user  with  the  relevant  award 
information.  The  buyers  make  their  award  decision  on  DESC  Form  701.  As  this  is  the 
format  they  are  accustomed  to  seeing,  design  of  the  prototype  output  screens  was  based  on 
this  form.  The  intent  of  this  decision  was  improved  user  acceptance.  It  was  felt  the  buyers 
would  be  less  resistive  to  a  new  system  if  the  system  manifested  itself  in  a  form  familiar 
to  them.  Details  on  the  user  screens  will  be  covered  later. 

Paper  Prototype 

With  the  primary  inputs  and  outputs  of  the  system  identified,  a  paper  prototype  was 
developed.  This  ’Desk-top’  model  consisted  offlow  charts  identifying  major  logic  concepts 
and  sketching  of  the  display  screens. 

Components.  Figure  4-1  depicts  the  introductory  flow  chart  developed.  The  purpose  of 
these  high  flow  charts  is  to  bring  structure  to  the  software  design.  The  detail  in  these  charts 
is  only  sufficient  to  identify  the  major  inputs  to  the  system,  its  major  processing  blocks  and 
the  outputs  provided  to  the  buyer.  It  provides  a  functional  view  of  the  system's  primary 
components  and  its  major  decision  points. 

Inputs.  The  inputs  to  the  system  were  identified  as  follows: 

a)  NSN  of  the  item  requested; 

b)  The  Quantity  requested;  and, 

c)  Identification  of  a  Set-A-Side  procurement.  (In  the  form  of  Yes  or  No). 
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FIGURE  4-1  --Imtai.  Fix)w  Diagram 


Outputs.  The  outputs  the  buyers  required  from  the  system  to  make  the  award 
decision  were  identified  as  follows: 

a)  Vendors  who  offer  the  item  for  sale, 

b)  Minimum  quantity  the  vendor  will  sell  that  satisfies  the  requirements  of  the 
purchase  request. 

c)  The  price  of  that  quantity, 

d)  Whether  the  vendor  offers  an  attractive  price  reduction  for  a  larger  order, 

e)  Total  price  of  the  purchase  request, 

f)  Early  payment  discounts, 

g)  Freight  Charges  (FOB  Origin/Destination),  and 

h)  Past  vendor  performance  data. 
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The  user  screens  were  developed  using  grid  paper.  The  grids  were  representative 
of  CRT  screen  size  the  buyer  would  be  using.  From  these  drawings,  a  programmer  can 
identify  the  required  coordinates  of  specific  display  data.  This  greatly  eases  later  software 
coding. 

Because  of  constraints  of  the  computer  CRT  (Cathode  Ray  Tube),  (sometimes 
referred  to  as  the  monitor)  the  information  required  is  presented  on  three  screens.  The  first 
screen  is  the  Unit  pricing  screen.  This  screen  will  inform  the  buyer  of  the  vendors  bidding 
on  a  component,  the  quantity  breaks  offered  by  the  vendor,  and  the  price  per  unit  for  a 
specified  quantity.  The  second  screen  is  the  extended  price  screen.  Its  design  is  based  on 
the  unit  pricing  screen.  It  differs  from  the  unit  pricing  screen  in  that  the  prices  displayed 
in  the  matrix  represent  unit  cost  times  the  quantity.  The  final  screen  is  the  detailed  vendor 
information  screen.  This  screen  identifies  the  vendor  by  name,  specific  shipping 
information,  discounts  offered  for  prompt  payment,  and  a  record  of  occurrence  in 
supporting  data  files. 

Review.  The  Desk-top  Model  was  presented  to  DESC  management  for  their  review  and 
comments.  Details  of  the  proposed  prototype  operation  were  narrated.  This  included  the 
identification  of  primary  data  files  indigenous  to  the  prototype  and  the  data  requirements 
from  supporting  systems.  Screen  descriptions  were  presented  in  the  same  sequence  as  the 
proposed  prototype  would  generate  them.  Since  DESC  users  offered  no  significant  changes 
to  the  model,  transition  into  the  next  phase  of  software  development  began. 

Initial  Prototype  Development 

Design  Considerations. 

Data  Requirements.  To  be  useful,  the  prototypie  must  interrogate  several  data  files 
for  information.  Some  of  the.se  files  reside  on  other  computer  systems,  others  reside  on 
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printed  paper  tucked  in  a  drawer.  For  those  files  that  currently  exist  in  an  electronic  format, 
the  data  were  extracted  and  used  without  manipulation.  For  those  files  yet  to  be  created, 
arrangement  of  the  data  elements  to  simplify  integration  with  existing  prototype  software 
modules  was  emphasized.  The  major  data  files  considered  for  use  in  the  initial  prototype 
are  identified  as  follows: 

1)  NSN  file.  Lists  all  items  for  which  the  prototype  contains  pricing  information. 

2)  Price  file.  Contains  all  pricing  data  for  the  items  identified  in  the  NSN  file. 

3)  Vendor  file.  Contains,  by  cage  code,  vendor  specific  information,  i.e.,  delivery 
time,  type  of  vendor,  and  cage  code  for  those  vendors  providing  bids  on  the  items 
in  the  NSN  file. 

4)  DCRL  file.  Contains,  by  vendor,  specific  details  of  past  performance  problems. 

5)  Due-ln  file.  Contains,  by  NSN,  information  on  products  ordered  but  not  yet 
delivered. 

6)  History  file.  Contains,  by  NSN,  past  procurement  information  for  a  specific 
product. 

7)  Quality  file.  Contains,  bycagecode,  those  vendors  identified  in  DESC’s  quality 
vendor  program. 

Data  Files.  The  data  files  used  in  the  initial  prototype  were  for  developmental 
purpo^es  only.  They  were  not  complete.  Some  data  files  contained  only  a  few  representative 
records  from  the  real  world  data  files.  Other  data  files  were  constructed  before  the  actual 
data  files  became  available.  In  this  instance,  the  necessary  data  element  was  contrived  based 
on  the  information  that  would  be  required  for  successful  implementation.  This  short  coming 
will  be  discussed  further  in  the  next  section. 

Data  Structure.  Certain  characteristics  of  the  raw  data  were  exploited  to  simplify 
prototype  design. 
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For  example,  there  is  a  one  for  one  relationship  of  Type  number  to  National  Stock 
Number  (NSN).  The  NSN  appears  at  the  top  of  each  purchase  request.  The  NSN  is  also 
a  key  field  used  to  interrogate  other  data  files  currently  maintained  at  DESC,  for  example, 
the  History  and  Due-ln  data  files.  The  prototype  was  designed  to  request  the  NSN  instead 
of  the  Type  number.  This  decision  was  made  as  the  NSN  is  readily  available  to  the  buyer, 
and  it  would  eliminate  a  cross-referencing  step  by  the  system. 

A  second  code  appears  in  virtually  every  vendor  related  operation  in  the  current 
system.  That  code  is  the  Cage  code.  The  cage  code  is  a  five  position  alpha-numeric  element 
that  uniquely  identifies  a  vendor.  This  alias  becomes  a  si'orthand  the  buyers  use  to  refer 
to  a  specific  vendor.  The  function  of  the  cage  code  in  the  prototype  will  be  covered  later. 

To  reduce  the  amount  of  data  storage  space  required  for  each  item  the  following 
procedure  was  adopted.  Instead  of  storing  a  price  schedule  with  each  item,  a  code  was 
devised  to  identify  a  unique  set  of  prices.  All  products  from  the  same  vendor  with  the  same 
pricing  scheme  are  assigned  the  same  code.  This  technique  saved  one  hundred  ninety-four 
bytes  of  storage  space  for  each  part  on  fde.  The  resulting  NSN  data  file  record  length  is 
only  thirty-four  bytes  long.  When  the  prototype  integrates  into  VASPP,  it  must  rely  on 
vendor  pricing  information  stored  in  a  central  data  file.  The  data  contained  within  this  data 
file  will  be  submitted  and  maintained  by  the  vendor.  The  structure  of  this  database  is  not 
yet  determined.  An  outcome  of  this  research  will  be  the  minimum  data  elements  the  vendors 
must  supply  for  successful  implementation.  The  complete  details  of  the  pricing  data 
structure  used  and  a  description  of  each  data  element  used  can  be  found  in  Appendix  C.  (This 
appendix  contains  the  data  description  for  all  data  bases  used.) 

The  prototype  must  search,  without  intolerable  delay,  a  data  file  containing 
thousands  of  records  (assuming  at  least  one  record  per  item).  For  example,  the  MilSpec 
55  1 82  Items,  a  single  subset  of  the  items  in  Stock  Class  5905,  contains  over  50.000  entries. 
To  expedite  this  process,  two  design  features  were  incorporated  into  the  system.  The  first 


4-7 


was  to  minimize  the  elements  contained  in  the  larger  data  files.  Reducing  the  size  of  the 
datafile,  reduces  the  number  of  bytes  the  system  must  transfer  between  the  storage  area  and 
the  processing  unit  where  it  can  analyze  the  information. 

The  second  technique  makes  use  of  indexed  files  wherever  possible.  Indexing  is 
es.sentially  a  refinement  to  minimizing  file  size.  The  concept  of  an  index  file  is  as  follows. 
A  separate  file  is  created  containing  two  elements.  The  first  element  is  called  the  key  field. 
In  this  example,  it  is  the  NSN.  The  second  field  contains  the  position  (the  record  number) 
in  the  main  database  that  contains  the  Key  element.  The  system  rapidly  searches  the  smaller 
index  file  for  the  Key  (the  NSN).  Once  located,  it  can  make  a  direct  reque.st  for  the  data 
record  of  interest  in  main  data  file. 

Software  Development. 

Methodology.  The  software  was  designed  in  modular  format,  taking  care  to  make 
each  unit  as  independent  from  the  other  modules  as  possible.  This  technique  leads  to  easier 
testing  and  modification  (27:62).  As  each  module  was  developed,  it  was  checked  for  proper 
operation;  examining  both  extremal  and  special  values.  Unexpected  results  were  corrected 
prior  to  continuing  with  the  next  stage  of  program  development. 

Beyond  generating  the  program  code,  internal  documentation  was  concurrently 
produced.  With  the  task  of  the  software  manager  in  mind,  these  programming  notes  were 
placed  in  the  code  to  assist  in  future  debugging  or  program  modifications. 

fnvironment  Selection.  Through  interviews,  it  was  learned  personnel  in  DfSC's 
automation  department.  nii.S('-Z.  were  familiar  with  Ashton-Tates  software  known  as 
dBase  ///  Plus.  (.)ne  of  this  program's  mam  strengths  is  its  ability  to  assist  the  user  in 
performing  complex  database  manipulations  and  retrievals.  The  programming  approach 
to  the  problem,  being  heavily  reliant  on  data  retrieval  (the  final  prototype  integrates  eleven 


separate  data  files),  and  the  author's  own  acquaintance  with  the  program,  made  dBase  III 
Plus  a  natural  choice  for  use  on  this  project. 

System  Description.  The  following  narrative  describes  the  operational  process 
designed  into  the  prototype.  Only  major  actions  performed  by  the  prototypie  are  covered. 
(The  reader  may  find  it  useful  to  refer  to  the  initial  flow  charts  of  Figure  4-1). 

The  first  thing  the  user  sees  when  starting  the  system  is  a  welcome  screen  (Figure 
4-2).  This  screen  simply  identifies  the  software  and  asks  the  user  to  proceed  when  ready. 
The  second  screen,  Figure  4-3,  provides  a  brief  description  of  the  software  and  informs  the 
user  of  the  inputs  required  to  use  the  system  successfully.  The  user  has  the  opportunity  to 
exit  the  system  at  this  point  or  continue  to  the  next  screen. 

The  third  screen ,  Figure  4-4,  is  the  first  of  the  input  screens.  Prompts  for  information 
are  presented  sequentially.  The  first  item  requested  is  the  NSN.  Once  entered,  the  system 
accesses  the  NSN  data  base.  If  the  NSN  input  by  the  user  is  not  on  file,  the  user  is  informed 
and  allowed  to  reenter  the  requirement  (Figure  4-5).  Once  the  user  enters  an  NSN  contained 
in  the  data  base,  the  system  prompts  for  the  quantity  required  (Figure  4-6).  The  system 


Press  Any  Key  To  Continue 


FIGl'RE  4-2  -  W|ir..MI  SrkMN 
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verifies  a  numeric  value  was  entered  and  presents  the  final  prompt,  Set-A-Side  (Figure  4-7). 
If  the  purchase  request  is  identified  to  be  set-a-side  for  small  business,  the  user  enters  a  ‘  Y’ 
If  not,  the  user  enters  an  ‘N’ .  If  the  user  is  unsure,  the  system  will  accept  a  ‘7’ ,  and  treats  it 
as  an  ‘N’.  This  provides  the  user  with  all  qualified  vendors. 


The  Automated  Vendor  Selection  Assistant 
selects  the  vendor(s)  who  have  competitively  bid 
on  the  item  of  interest. 

To  proceed,  you  must  know  the  item's  MSN 
and  the  quantity  required. 


Do  you  wish  to  continue?  <T/M>T 
FIGURE  4-3  PkOdHAM  IMOKMAITON  ScKI.I.N 


Enter  the  MSN  of  the  item  to  be  procured 
5905-01009-5543 


-(Press  <CR>  when  complete) 


Press  <ESC><ESC>  to  Quit  the  Assistant 


FKiURE  4-4  --  NSN  Kri  i  ,S(  mis 
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Enter  the  NSN  of  the  item  to  be  procured 
5905-01-009-5555 

This  NSN  is  not  on  file 

L— - (Press  <CR>  when  conplete) - 

Press  <ESC><ESC>  to  Quit  the  Assistant 

FIGURE  4-5  -  NSN  Not  On  Fii>:  Screen 


Enter  the  NSN  of  the  ite»n  to  be  procured 
5905-01-009-5543 

Enter  the  quantity  required 
90  EA. 

- (Press  <CR>  when  complete) - 


Enter  <0><CR>  To  Quit 
W:i'Rt  4T  ■  Qi  \N  nrv  Im’I  i  Scki  i  n 
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Enter  the  NSN  of  the  item  to  be  procured 
5905-01-009-5543 

Enter  the  quantity  required 
90  EA. 

- (Press  <CR>  when  cooptete) - 

Is  this  procurement  Set-Aside  for  small  business?  <Y/N/?> 

FIGURE  4-7  -  Si;T-A-Sidi:  Scrij-.n 

The  system  now  has  all  the  information  required  for  processing.  It  scans  the  NSN 
data  base  to  locate  all  vendors  who  have  bid  on  the  item.  Each  vendor’s  pricing  data  for 
the  item  are  transferred  to  a  temporary  data  file.  The  vendors  in  the  temporary  data  file 
are  then  compared  to  the  DCRL  file.  If  a  vendor  is  identified  in  the  DCRL  file  as  'DeBarred' 
it  is  removed  from  the  temporary  data  file.  (A  DeBarred  vendor  is  ineligible  to  receive  any 
contract  awards.) 

If  it  is  a  set-a-side  procurement,  the  temporary  file  is  scanned  again,  this  time  looking 
for  vendors  coded  as  ‘large  vendors’.  Those  vendors  are  removed  from  the  file.  After  this 
two  step  process,  the  only  vendors  remaining  in  the  temporary  file  are  those  that  are  eligible 
to  receive  the  contract  award. 

If.  after  completing  these  two  procedures,  there  are  no  vendors  qualified  to  receive 
the  award,  the  buyer  is  informed  (Figure  4-8)  and  returned  to  the  information  screen.  The 
buyer  can  cither  fail  to  make  the  award  or  can  relax  the  requirements  and  reprocess  the 
request. 
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No  qualified  vendors 
are  on  file  matching 
your  requirements. 

Press  Any  Key  To  Continue 


FIGURE  4-8  --  No  Qi  AiiiThD  Vrndor  Screen 


Now  that  the  vendors  bidding  on  the  item  are  known,  the  system  makes  several 
background  checks.  The  DCRL  and  quality  data  files  are  scanned.  The  vendor’s  cage  code 
is  the  Key  element  used  to  perform  the  look-up.  The  Due-In  file  is  checked,  using  the  NSN 
of  the  items.  The  results  of  these  searches  are  recorded  by  setting  specific  flags  assigned 
to  each  vendor.  If  a  *hit’  was  made,  the  appropriate  flag  is  set  to  'True'. 

The  system  now  focuses  on  the  pricing  data.  It  calculates  the  minimum  quantity  of 
items  that  can  be  ordered,  while  still  satisfying  the  Purchase  Request.  Each  vendor  has 
different  minimum  quantity  requirements.  Some  vendors  will  only  sell  in  specific  lot  sizes. 
In  this  case,  the  system  increases  the  order  quantity  to  the  value  of  the  next  lot  size. 
Sometimes  the  lot  size  varies  with  the  quantity  ordered.  The  system  can  adjust  the  order 
quantity  accordingly.  One  final  check  made  for  each  vendor  is  the  minimum  order  dollar 
amount.  Again,  if  the  requested  quantity  times  the  unit  price  of  the  item  is  below  the 
minimum  dollar  amount,  the  order  quantity  is  increased  to  the  minimum  quantity  that  will 
meet  the  minimum  dollar  order  thre.shold. 
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Once  the  appropriate  minimum  order  quantity  for  each  vendor  is  determined,  that 
and  any  additional  relative  pricing  data  are  transferred  into  a  second  temporary  storage  file. 
In  this  file,  the  order  quantities  are  sorted  in  ascending  order,  and  the  lowest  price  offered 
is  identified.  The  low  price  is  compared  to  past  purchases.  Appropriate  flags  are  tripped 
if  any  deviations  are  found.  These  flags  will  be  used  to  trigger  the  display  of  appropriate 
warning  messages  for  the  buyer. 

From  this  temporary  file,  the  data  are  transferred  into  a  series  of  memory  variables. 
These  memory  variables  are  organized  to  form  a  two-dimensional  table.  The  information 
presented  in  the  user  pricing  screens  comes  directly  from  this  memory  table.  The  columns 
of  the  table  represent  the  various  quantities  of  the  product  that  can  be  purchased.  The  rows 
identify  the  vendors  that  offer  the  item  for  sale.  At  the  intersection  of  a  given  row  and 
column  is  the  pricing  data  related  to  that  specific  vendor/quantity  intersection. 

The  eligible  vendors  offering  the  item  for  sale  have  been  identified.  Performance 
records  have  been  checked.  The  minimum  quantity  the  vendor  is  willing  to  sell,  that  meets 
or  exceeds  the  quantity  requested,  is  identified.  Once  the  lowest  total  price  that  satisfies 
the  purchase  request  has  been  identified,  the  data  are  now  ready  for  display. 

The  next  step  is  for  the  system  to  present  the  output  screens  to  the  user.  The  first 
screen  presented  is  the  extended  price  screen  (Figure  4-9).  This  screen  informs  the  buyer 
which  vendors  sell  the  product,  and  their  total  price  for  a  given  quantity  of  the  product.  The 
vendor  cage  code  is  color  coded  corresponding  to  its  appearance  in  the  DCRL  file,  the  Due- 
In  file,  or  the  Quality  file.  The  logic  governing  the  color  code  assigned  has  a  designated 
order  of  hierarchy.  Color  coding  for  a  vendor  found  in  the  Due-In  file  will  override  an 
appearance  in  the  Quality  file.  Also,  appearance  in  the  DCRL  file  will  override  all  other 
color  coding 

Pricing  information  is  a!  so  color  coded.  The  lowest  total  price  to  satisfy  the  purchase 
request  is  highlighted  bright  green.  If  there  is  a  tie  between  vendors,  both  low  quotes  will 
be  highlighted.  If  the  low  price  is  ‘considerably’  lower  than  the  next  lowest  vendor's  price. 
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the  low  price  is  highlighted  yellow.  (This  feature  alerts  the  buyer  that  the  price  may  be 
unrealistic).  What  identifies  a  price  as  considerably  lower  is  controlled  by  the  Model  data 
file.  Additional  elements  of  the  model  subsystem  will  be  discussed  later. 


Pricing  Data  For:  5905-01-009-5543 


90 

100 

200 

250 

300 

500 

56856 

0BTU6 

6S313 

128.70 

114.00 

25.50 

92.00 

234.00 

450.00 

385.00 

00001 

136.00 

■ 

VENOORzH  Problem  Vendor  PRIC£:§  Price  May  Be  To  Low 

I  Items  Due-In  From  Vendor  |  Low  Price 

I  Qua  I i ty  Vendor 


<SPACE  8AR>  To  Toggle  Screens  <ESC>  When  Finished 


FIGURE  4-9  -  ExTiiNDiiD  Pwci-:  S('rj;i;n 


Pressing  the  space  bar  toggles  to  the  vendor  screen  (Figure  4-10).  This  screen 
displays  the  vendor  delivery  information  and  informs  the  buyer  if  the  vendor  is  identified 
in  any  of  the  supporting  historical  performance  files. 

Pressing  the  space  bar  again  brings  up  the  unit  pricing  screen  (Figure  t-l  1).  This 
screen  is  identical  with  the  extended  pricing  screen  except  the  prices  in  the  matrix  are  ‘per 
piece'. 

The  buyer  can  continue  toggling  between  these  screens  until  the  award  decision  is 
made.  Pressing  <  ESC  >  will  return  the  system  to  the  program  information  screen.  Once 
back  to  that  screen,  the  buyer  can  either  enter  a  ‘  Y’  to  make  another  inquiry,  or  an  ‘N’  to 
terminate  the  session. 
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The  Model  Component.  In  addition  to  the  discrimination  and  mathematical 
calculations  already  discussed,  the  model  data  file  controls  how  and  when  specified 
information  is  presented  on  the  screen.  The  values  contained  within  the  model  can  be 
changed  at  the  request  of  the  management.  At  this  stage  of  development,  the  model  controls 
the  following  display  attributes; 

a)  Low  Price  Flag.  This  element  alerts  the  buyer  to  the  fact  that  the  vendor  is 
quoting  a  price  that  is  significantly  lower  than  the  competitors.  When  tripped, 
the  low  price  will  be  displayed  in  yellow  on  the  pricing  screens. 

b)  No  History  Flag.  The  number  stored  in  this  element  represents  a  dollar  threshold 
value.  If  the  unit  price  of  an  item  exceeds  this  amount,  and  there  is  no  historical 
purchase  information  on  file,  a  message  is  printed  on  the  output  screens. 

c)  Exceeds  History  Price.  The  prototype  compares  the  item’s  current  unit  price 
with  the  unit  price  of  the  item  when  last  ordered.  If  the  current  unit  price  exceeds 
the  last  unit  purchase  price  by  more  that  the  percentage  contained  in  the  element, 
a  message  is  presented  to  the  buyer. 

d)  Excessive  Contract  Value.  If  the  total  value  of  the  award  exceeds  the  dollar 
amount  stored  in  this  element,  a  warning  is  printed  on  the  screen  informing  the 
buyer  the  limit  for  small  contract  award  has  been  exceeded. 

e)  Variation.  On  the  price  list  the  vendor  identifies  any  variations  in  shipping 
quantity.  The  vendors  claim  authorization  to  ship  a  quantity  within  a  stated 
{percentage  of  the  contract  quantity.  For  example,  a  vendor  may  claim  a  variation 
of  two  percent.  If  the  contract  was  written  for  one  hundred  units,  the  vendor 
could  ship  only  ninety-eight  units  and  still  satisfy  the  contract.  The  prototyfie 
checks  this  variation,  internally  increments  the  quantity  to  account  for  the 
variation,  and  computes  the  resulting  award  value  of  the  contract.  If  the  award 
value  exceeds  the  excessive  contract  value,  (defined  above),  a  warning  is 
provided  on  the  user  screens. 
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Review.  A  formal  presentation  of  the  prototype  was  given  to  the  DESC-P,  suppo- ing 
management,  and  selected  buyers.  The  purpose  of  this  review  was  to  insure  the  overall 
design  of  the  prototype  conformed  to  DESCs  expectations.  This  pre-inspection  was 
necessary  to  avoid  the  possibility  of  extensive  programming  hours  consumed  in 
unproductive  areas.  This  however,  was  not  so.  The  initial  prototype  was  reviewed  with 
great  enthusiasm.  The  design  met  or  exceeded  their  anticipations  for  this  first  review. 
Minor  modifications,  discussed  below,  were  suggested.  Without  reservation,  the  initial 
prototype  was  accepted  and  plans  were  made  to  proceed. 

Full  Prototype  Development 

Having  gained  approval  of  the  basic  design,  attention  was  turned  to  developing 
a  complete  working  prototype. 

Requirements  Re-evaluation.  To  pin  down  the  exact  characteristics  the  next  prototype 
required,  a  meeting  with  several  buyers  and  management  personnel  was  scheduled  for 
the  following  week.  At  this  meeting  comments  were  solicited  regarding  the  current 
system  design.  A  detailed  examination  of  each  screen  was  made.  Attention  was  given 
to  the  data  presented,  making  sure  all  information  required  to  make  the  award  decision 
was  accounted  for.  Also  critiqued  was  the  presentation  format  of  for  each  screen.  Any 
changes  suggested  were  recorded.  Documented  in  the  next  section  are  those  changes. 

Modifications.  Unless  otherwise  noted,  the  fully  developed  prototype  maintains  all  the 
operational  characteristics  described  for  the  initial  prototypie  (see  Initial  Prototype 
Development  for  details).  Changes  to  the  prototype  fell  into  two  categories,  embellish¬ 
ments  of  existing  features  and  enhancements  of  new  features  suggested  by  the  review 
panel. 
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Embellishments.  Several  features  of  the  initial  prototype  were  not  yet  functional 
prior  to  its  review.  Two  user  screens  had  yet  to  be  developed.  The  first  was  the  DCRL 
information  screen. 

The  prototype  syntax  refers  to  this  screen  as  the  ‘Problem  Vendor  Screen’.  If  a 
bidding  vendor  appears  in  the  DCRL  data  file,  the  cage  code  is  highlighted  red.  To  see  the 
information  contained  in  the  file,  the  buyer  enters  ‘P’  from  any  of  the  user  screens  and  the 
discrepancy  details  for  that  vendor  appears  on  a  new  screen  (Figure  4-12).  When  the  buyer 
finishes  reviewing  the  file,  he/she  is  returned  to  the  previous  user  screen. 


[  6S313 

SECOM  ELECTRONICS  CORP 

89/11/15  D  Pre- Award  Survey  Required 

12  PROGRESS  PLACE 

JACkSON  NJ  08527-3002 

see  P  ton  20  OCT  89  RE  UNSRTISMCTORT  PERFORMANCE 
RECOMMEND  DETERMINATION  OF  NONRESPONSI BI L I TT , 
PREAWARD  SURVEY,  DCAS  ADMINISTRATION 


Press  any  key  to  continue... 


FIGURE  4-12  -  Pkoim.i  \i  Vcnmok  Sckt.tn 


The  second  screen  not  developed  for  the  initial  prototype  was  the  Due-in  Screen. 
The  Due-In  data  file  was  not  available  for  review  when  the  initial  prototype  was  developed. 
Request  to  DESC  for  a  copy  of  their  actual  file  was  unsuccessful  in  providing  a  product  that 
was  usable  for  this  project.  A  file  was  available  that  identified  the  items  Due-In.  but  there 
was  no  linkage  made  to  the  vendor  responsible  for  filling  the  order.  Because  of  the  inability 
to  track  an  order  to  the  vendor  providing  it.  this  portion  of  the  prototype  became 
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dysfunctional.  This  problem  was  reported  to  DESC.  After  discussion  with  management 
and  buyers,  the  determination  was  made  that  this  specific  information  was  not  critical  to 
the  award  decision  process.  It  was  information  that  would  be  useful  if  available  to  the 
buyers,  but  its  absence  would  not  critically  impede  the  decision  process. 

Yet  another  screen  required  in  the  system  was  an  award  screen.  Once  the  buyer 
selects  the  best  vendor  to  receive  the  award,  a  DESC  Form  800  must  be  filled  out.  The 
Award  Screen,  (Figure  4-13),  pulls  together  all  the  information  required  to  completea  this 
form. 
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FIGl'RE  4-13  -  Award  Si  rm  n 

In  the  fully  functional  prototype,  historical  information  regarding  past  buys  was  not 
only  examined,  as  in  the  initial  prototype;  but  also  displayed  for  the  buyers’  use.  If 
procurement  information  for  the  item  is  found  in  the  Historical  data  fi.e,  the  most  recent 
purchase  information  is  displayed  in  the  upper  right  hand  corner  of  either  Pricing  Screen 
(see  Figure  4-14).  This  provides  the  buyer  with  not  only  the  vendor  and  price  of  the  last 
order,  hut  gives  the  buyer  an  estimate  regarding  the  rate  of  consumption. 
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**•  UNIT  PRICE  EXCEEDS  HISTORY 
Extended  Pricing  Data  For:  5905-01-009-5543 
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From  91637  For  SO. 27 
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FIGURE  -1-14  -  ‘FiNAi  ■  Extt.ndi.d  Prici;  Scrki  n 


Enhancements.  The  next  paragraphs  identify  changes  made  to  the  prototype  as 
suggested  by  the  review  panel. 

Customer  Depot  Complaint  File  (CDCF).  A  second  'problem'  file  was 
identified.  The  CDCF  was  a  listing  by  NSN  of  items  that  have  had  complaints  registered. 
The  complaints  can  be  anything  from  substandard  product  performance  to  mismarked 
packaging.  The  prototype  incorporates  this  data  file  using  the  foiiowing  method.  First, 
it  checks  for  the  existence  of  the  NSN  in  the  CDCF  data  file.  If  the  NSN  exists,  a  search 
is  conducted  within  the  NSN  for  a  cage  code  matching  any  of  the  bidding  vendors.  If  a 
bidding  vendor  is  found  to  have  a  complaint  filed  on  the  product  in  question,  the  CDCF 
flag  is  set  for  that  vendor.  When  the  cage  codes  are  displayed  on  the  user  screens,  the  cage 
is  color-coded  violet.  The  buyer  can  review  the  contents  of  he  relevant  CDCF  records  using 
the  CDCF  screen.  Figure  4-15. 

Required  Delivery  Date  iRDD).  It  was  suggested  the  buyer  make  an 


additional  input  to  the  prototype  and  enter  the  RDD  date.  The  Requited  Delivery  Date 


is  the  Julian  date  the  item  is  required  for  use.  It  can  be  found  on  the  last  page  of  the 
purchase  request. 
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DISC  -->  Q5 

CAUSE  ->  CN  CONTRACTOR  NONCOHPLIANCE  (PRIME  CONTRACTOR) 

DISP  -->  AO  DALE  -  CAT  I  -  OAC  FROM  C/C  "K"  TO  C/C  "H"  W/MGMT  CODE  " 
CORR  -->  AO  POC  BETTY  GEBELE/OSIB/AV986-6486. 


Prpss  any  key  to  continue... 


FIC.V  RE  4-15  --  CDCF  S.  hi  i  n 


The  input  screen  was  modified  to  accommodate  this  additional  input  (Figure  4- 
16).  After  the  buyer  enters  the  quantity  ot  the  item  required  and  before  he/she  indicates 
the  Set-A-.Side  status,  the  system  now  asks  for  the  RDD  date.  The  prototype  performs 
a  validation  check  on  the  buyer’s  input.  The  input  is  a  five  digit  numeric.  The  first 
two  positions  represent  the  last  two  digits  of  the  year.  The  next  three  positions  represent 
the  day  of  the  year.  Because  DESC  habitually  receives  purchase  requests  with  required 
delivery  dates  prior  to  the  day  of  receipt,  the  system  will  accept  one  year  prior  to  the 
current  year.  The  system  will  accept  the  day  input  if  it  is  a  number  between  one  and 
three  hundred  sixty-five  inclusive.  (Three  hundred  sixty-six  is  accepted  if  the  year 
entered  is  a  leap  year.) 


Enter  the  NSN  of  the  item  to  be  procured 
5905-01-009-5543 

Enter  the  quantity  required 
90  EA. 

(Press  <CR>  when  complete) - - - 

What  is  the  ROD  date?  92105 

FIGURE  4-16  -  Ri.qi  iKi'.i)  Dcijvi  ky  Date  Inpi  t  S<'r1:i;n 

The  vendor  information  screen  and  the  model  were  modified  to  take  advantage  of 
this  information  (see  Figure  4-17).  An  additional  element  was  added  to  the  model  for 
administrative  lead  time.  This  is  the  in-house  time  required  to  process  the  award  paper  work. 
The  system  calculates  the  current  Julian  date.  To  that,  the  administrative  lead  time  is  added. 
Also  added  is  the  vendor's  stated  delivery  time.  The  current  date,  plus  the  Administrative 
Lead  Time,  plus  the  Delivery  Time  is  the  Projected  Delivery  Date.  The  delivery  projection 
IS  compared  against  the  required  delivery  date.  If  a  vendor  can  deliver  on  or  before  the 
required  delivery  date,  the  projected  delivery  date  is  displayed  as  green.  If  a  vendor  cannot 
meet  the  required  delivery  date,  the  projected  delivery  date  is  displayed  in  red. 

Also  modified,  was  the  coding  of  the  fully  developed  prototyp  e  to  give  the  buyer 
better  control  and  access  to  the  user  screens.  In  the  initial  prototype  the  user  toggled  through 
the  screens  using  the  space  bar.  The  order  of  presentation  was  fixed.  The  prototype  now 
held  six  user  screens,  and  toggling  was  unsatisfactory.  A  menu  struct'  ’■e  was  developed 
allowing  the  user  to  move  directly  to  the  menu  of  choice. 
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Vendor  Data  For:  5905-01-009-55A3 
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<U>  Unit  Pricing  <A>  Award  Screen 
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<C>  CDCF  Vendor  Detail 
<P>  Problem  Vendor  Detail 


FIGURE  4-17  —  ■  Final'  Vlndok  Scki  ln 


Data  [-iles.  The  data  files  used  with  this  prototype  were  extracted  or  created  from  the  actual 
files  found  at  DESC. 

1 )  NSN.  To  create  the  NSN  data  file.  The  programmers  at  DESC-Z  Generated  an 
extract  from  their  master  file.  The  extract  contained  only  those  NSNs  associated 
with  MilSpec  55182  item.  Even  with  this  reduced  subset,  it  took  nine  diskettes 
to  transfer  the  data. 

2)  Price.  This  data  file  was  created  from  the  hard  copy  price  lists  provided  by  the 
vendors.  Only  those  vendors  who  submitted  requests  for  MilSpec  55182  items 
were  included.  However,  each  vendor's  list  was  entered  in  its  entirety. 

3)  Vendor.  All  vendor  specific  information  required  by  the  system  is  stored  in  this 
file.  All  vendors  bidding  on  MilSpec  55182  items  are  included. 

4)  DCRL.  The  DCRL  data  file  is  an  image  of  the  complete  master  data  file  at 
DESC.  Thus  It  contained  all  vendors  DESC  recognizes  as  'problem  vendors' , 
and  identifies  their  transgressions. 

5)  CDCF.  Because  the  size  of  the  master  file  inhibited  transfer  to  floppy  diskettes, 
a  subset  was  used.  Again,  NSNs  associated  with  MilSpec  55 182  were  extracted. 
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6)  History .  Because  the  size  of  the  master  file  inhibited  transfer  to  floppy  diskettes, 
a  subset  was  used.  Again,  NSNs  associated  with  MilSpec  55 1 82  were  extracted. 

7)  Quality.  This  data  file  was  created  from  the  Quality  vendor  list  maintained  at 
DESC  and  entered  in  its  entirety. 

Design  Problems.  Two  design  problems  surfaced  while  developing  the  prototype.  One 
problem  dealt  with  the  data  structure  and  one  problem  dealt  with  the  program  coding. 

Data  Structure.  The  most  challenging  asfiect  of  the  development  efforts  rested  with 
the  pricing  data  itself.  For  a  relational  data  structure  to  work,  the  data  must  be  organized 
in  a  standardized  format.  That  is  not  so  with  the  pricing  information  provided  by  the 
vendors. , 

There  was  no  commonality  within  the  product  groups.  The  quantity  at  which  price 
changes  occurred  were  inconsistent.  Some  vendors  had  a  minimum  order  quantity,  other 
vendors  had  minimum  dollar  amounts.  Some  vendors  would  sell  individual  units,  while 
others  would  only  .sell  individual  units  over  a  certain  quantity.  Still  other  vendors  would 
only  sell  in  specified  lot  sizes. 

Consistency  had  to  be  brought  to  these  variances.  The  design  of  the  pricing  data 
file  achieved  most  of  this  goal .  It  uses  three  fields  to  identify  a  price:  the  minimum  quantity 
for  a  grouping,  the  maximum  quantity  for  a  grouping,  and  the  unit  price  for  that  grouping. 
There  are  ten  sets  of  these  price  groupings.  Therefore,  a  vendor  can  provide  up  to  ten 
different  quantity  price  breaks  for  a  product. 

The  vendor  information  tile  is  used  to  solve  the  problem  of  lot  size  and  minimum 
order  quantity.  FJemerits  were  added  to  the  file  structure  for  these  two  values.  When 
calculating  the  pricing  information,  the  prototype  checks  these  two  elements  and  responds 
according  to  their  contents. 
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Program  Coding.  Most  of  the  coding  required  to  produce  the  prototype  was 
conventional  in  nature.  The  use  of  indexes,  and  linking  several  data  files  with  key  fields,  cire 
typical  data  file  procedures.  The  most  challenging  feature  of  the  coding  was  the  display 
matrix. 

Following  are  the  steps  developed  to  organize  the  matrix.  First,  vendor  pricing 
groups  that  contain  insufficient  quantities  to  satisfy  the  purchase  request  are  eliminated.  The 
remaining  pricing  data  are  transferred  to  a  temporary  data  file.  This  process  is  repeated  for 
all  bidding  vendors.  With  all  pricing  information  in  the  temporary  file,  it  is  arranged  by 
ascending  order  quantity.  The  first  six  quantities  are  copied  into  the  memory  display  matrix. 
The  remaining,  if  any,  additional  quantities  are  removed  from  further  processing. 

Next,  the  pricing  information  is  transferred  into  the  display  matrix.  This  does  not 
have  to  be  such  a  challenge,  but  dBase  does  not  provide  for  array  variable  identification.  As 
a  result,  each  cell  in  the  matrix  must  be  uniquely  identified  and  addressed  individually.  The 
prototype  examines  the  pricing  information  in  the  temporary  data  base,  locates  the  proper 
vendor  row  in  the  matrix  and  finally  finds  the  prop)er  column  to  place  the  price. 

The  program  coding  required  to  perform  the  above  steps  can  be  found  in  the  program 
PrepVen.  line  numbers  124  through  215.  and  301  through  384  (Appendix  A). 

Verification 


Focus.  Once  all  desired  functions  and  features  of  the  prototype  were  coded,  the  official 
verification  phase  could  begin .  Some  additional  comments  on  the  software  development  are 
in  order  at  this  time. 

It  is  worthw  hile  to  rev  isit  the  idea  of  software  debugging.  While  it  is  a  noble  gesture 
to  strive  for  error-free  coding,  proving  it  is  so.  is  another  matter.  ‘Tfthe  objective  of  testing 
were  to  prove  that  a  program  is  free  of  bugs,  then  not  only  would  testing  be  practically 
impossible,  but  it  would  also  be  theoretically  impossible”  (6: 12). 

Verification  of  the  system  was  a  multi-step  process.  The  first  phase  involved  desk¬ 
top  review  of  the  program  ctxie  The  second  step  incorporated  was  path  verification 
procedures. 
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Desk-top  Review.  Prior  to  conducting  the  review,  the  program  code  was  analyzed  by  Snap, 
a  public  domain  documenting  program  for  dBase  source  files.  By  informing  Snap  of  the 
first  program  module  in  the  series,  it  is  able  to  analyze  the  entire  program  structure. 
Assuming  there  are  no  logic  errors  located.  Swap  continues  with  the  documenting  process. 
Through  a  series  of  user  selectable  switches,  it  can  convert  the  case  of  the  variables  and 
reserved  words  (i.e.,  forces  dBase  III  Plus  reserve  words  to  be  printed  in  capital  letters), 
tab  indentured  code,  number  the  program  lines  and  create  a  variable  cross  reference  table. 

With  these  enhancements,  it  was  possible  to  perform  an  in-depth  desk-top  review 
of  the  program  code.  Desk-top  review  consists  of  manually  examining  each  line  of  code, 
looking  for  peculiarities.  Some  details  examined  were:  submodule  sequencing,  redundant 
variables,  and  documentation  completeness.  Discrepancies  were  corrected  and  a  final  copy 
of  the  program  code  produced.  (Appendix  A)  (Figure  4- 18  depicts  the  final  system  design). 
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Path  Verification.  After  the  desk-top  review,  the  code  rested  in  its ‘final’  format.  Thecode 
was  inspected  by  hand  and  all  paths  through  the  system  identified.  Through  inspection,  the 
extremal  and  special  variables  were  identified  for  each  path. 

With  the  program  paths  identified,  each  path  was  tested  for  proper  execution  by 
means  of  altering  data  input  (either  through  the  user  prompts  or  by  altering  the  contents  of 
the  database).  Where  necessary,  values  were  artificially  assigned  to  program  variables. 
Any  unexpected  results  in  program  execution  were  examined  to  determine  their  origin,  and 
as  necessary,  corrections  made  to  the  program  code. 

User  Review.  With  the  prototype  complete  and  errors  checked,  a  meeting  was  scheduled 
with  personnel  at  DESC.  A  demonstration  of  the  system  was  provided  along  with  a 
description  of  the  enhancements  incorporated  since  the  last  formal  review.  As  before,  the 
prototype  was  well  received.  While  some  future’  enhancements  were  identified,  none 
offered  would  affect  the  functionality  of  the  prototype  (i.e.,  color  changes  on  the  screen), 
or  retard  the  validation  phase. 

With  DESC  management  satisfied  with  the  fully  developied  prototype,  the  design 
was  ‘frozen’.  Efforts  now  turned  to  the  formal  validation  process.  Details  of  this  step  can 
be  found  in  the  next  chapter. 

Conclusion 

This  chapter  recounts  the  development  and  resulting  verification  process  of  the 
prototype.  A  multi-stage  development  approach  was  used.  The  basic  process  included 
defining  the  requirements,  designing  a  system  to  match  the  requirements  and.  building  the 
design.  The  importance  of  close  coordination  with  the  user  cannot  be  o\er  emphasized. 
Without  user  input,  the  development  prrKess  could  have  easily  fallen  short  of  expectations. 
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V.  Validation 


Overview 

This  chapter  details  the  sequence  of  events  used  to  test  the  prototype  and  analyzes 
the  data  generated  from  those  tests.  As  described  in  Chapter  III,  the  test  plan  incorporated 
three  phases.  That  scheme  was  adhered  to  without  modification.  Two  problems  were 
discovered  after  reviewing  the  data,  requiring  further  analysis  beyond  that  described  in 
Chapter  III.  Recorded  in  the  pages  that  follow  are  the  details  of  all  testing  and  analysis. 

Phase  I 


vSynopsis.  The  purpose  of  Phase  1  is  to  determine  the  completeness  and  accuracy  of  the 
information  presented  by  the  prototype.  The  question  is  asked,  “Does  the  system  provide 
the  correct  information?’  This  phase  of  testing  was  completed  on  July  22,  1991 . 

As  requested,  DESC  provided  two  people  with  expertise  in  the  award  selection 
processofMilSpec  55182  items.  The  buyer  chosen.  Ms.  Racine  Taylor,  has  worked  in  this 
area  for  five  years.  Ms.  Carol  Vance  is  the  contracting  officer  for  MilSpec  55128  items 
and  was  the  second  member  selected  to  serve  on  the  Expert  panel. 

The  rescv  :her  provided  the  panel  with  approximately  forty  minutes  of  background 
information  and  prototype  training.  This  included  outlining  the  procedure  used  to  process 
the  purcha.se  requests  using  the  prototype  and  how  to  complete  the  forms  developed  for  this 
test.  It  was  stres.sed  that  time  was  not  being  measured  in  this  phase  of  testing.  The  only 
criteria  of  interest  was  the  accuracy  of  the  information  presented  by  the  prototype  and  the 
correct  vendor  selection  information  for  each  purchase  request. 

Testing.  Thirty  purchase  requests  were  provided  by  DESC  for  testing.  The  purchase 
requests  used  were  selected  from  those  awaiting  buyer  processing. 
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The  panel  began  the  testing  process  by  selecting  a  purchase  request  from  those  provided. 
First,  the  request  chosen  was  processed  using  the  existing  manual  system.  The  panel  used 
DESC  Form  701  to  document  this  process  (See  Figure  5-1).  Provided  with  each  purchase 
request  was  a  Panel  Selection  Form .  The  panel  annotated  the  vendor  chosen  in  the  Selection 
section  of  this  form  (Figure  5-2). 
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Having  selected  a  vendor  using  the  current  manual  process,  the  panel  next  used  the 
prototvpe  to  choose  the  appropriate  vendor.  Alter  entering  the  National  Stock  Number 
(NSN)  of  the  part  required,  the  quantity  requested,  and  the  Required  Delivery  Date  (RDD). 
the  prototvpe  interrogated  its  various  databases.  It  then  presented  the  panel  with  the  Net 
Price  Screen.  (Refer  to  Chapter  IV  for  a  discussion  of  the  various  user  screens.) 
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From  this  point,  the  panel  could  consult  the  net  price  screen  and  other  prototype 
screens  as  required.  To  review,  the  remaining  screens  are:  extended  pricing  data,  vendor 
delivery  data,  problem  vendor  data,  customer  complaint  data,  and  award  detail  data.  These 
screens,  in  concert,  provide  the  buyer  information  on  which  to  base  the  award  decision. 

Again,  the  panel  documented  the  award  information  on  the  attached  Panel  Selection 
Form.  This  two-step  process  of  vendor  selection  was  repeated  for  the  remaining  twenty- 
nine  purchase  requests  in  the  test  set.  Discussion  of  the  results  of  this  test  follows  in  the 
next  section. 

Once  processing  of  all  thirty  purchases  was  complete,  each  panel  member  received 
a  questionnaire.  The  responses  provided  on  the  completed  questionnaires  can  be  found  in 
Appendix  Ci. 

Results.  Table  5- 1  lists  the  data  obtained  from  the  first  phase  of  testing.  As  documented 
m  the  table,  the  information  from  the  prototype  system  provided  the  same  results  as  the 
current  manual  process  in  all  but  two  cases.  On  those  two  tKcasions,  the  pricing  data  base 
contained  an  error.  The  researcher,  in  reviewing  the  vendors  pricing  data,  misinterpreted 
the  vendors  price  list.  It  should  be  noted  that  the  prototype  displayed  the  pricing  information 
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TABLE  5-1 


as  intended  by  the  researcher.  However,  the  experienced  panel  quickly  revealed  this 
misunderstanding. 


Analysis.  A  Sign  Test  was  used  to  perform  statistical  analysis  on  the  data  for  this  phase 
(Figure  5-3).  Table  5-2  contains  the  data  set  used  in  the  analysis.  A  1  in  both  the  manual 
and  automated  columns  indicates  a  tie.  A  1  in  one  column  and  a  0  in  the  other  indicates 
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the  panel  preferred  one  method  over  the  other.  The  question  being  tested  is.  Is  there  a 
difference  in  the  award  selection  using  the  manual  process  versus  using  the  prototype?’ 
"The  null  hypothesis  tested  by  the  sign  test  is  that  the  median  of  the  differences  is  zero” 
(4:208). 


STATISriX  3.5 

ID:  Panel  Preference 

SIGN  TEST  FOR  MANUAL  -  AUTOMATED 

NUMBER  Of  NEGATIVE  DIFFERENCES  0 

NUMBER  OF  POSITIVE  DIFFERENCES  2 

NUMBER  OF  ZERO  DIFFERENCES  (IGNORED)  28 

PROBABILITY  OF  A  RESULT  ASOR  MORE  EXTREME  THAN  OBSERVED  0.2500 

A  VALUE  IS  COUNTED  AS  A  ZERO  IF  ITS  ABSOLUTE  VALUE  IS  LESS  THAN  l.OE-0005 
CASES  included  30  MISSING  CASES  0 


FIGURE  5-3  -  Sk.n  Ti.sr  For  Pam  i.  Pri  i  i.Kh.sci-. 


With  a  computed  one  tailed  p-value  of  .2500,  the  null  hypothesis  cannot  be  safely 
rejected.  In  other  words,  there  is  insufficient  statistical  evidence  to  show  the  vendor 
selections  differ  between  the  two  methods.  Therefore,  the  prototype  is  believed  to  be 
providing  the  panel  with  sufficiently  correct  information  on  which  to  base  the  award 
decision. 

fhe  panel  was  asked  to  respond  to  a  questionnaire.  The  final  question  the  panel 
responded  todealt  with  the  utility  of  the  prototype.  Both  panel  members  indicated  the  system 
did  have  the  potential  to  aid  the  buyer  in  the  vendor  selection  process.  Thus,  the  decision 
was  made  to  proceed  with  Phase  II  testing. 

The  vendors  selected  for  each  purchase  request  in  this  phase  of  testing  are  considered 
to  be  the  correct  answers  against  which  to  judge  the  vendor  selection  responses  of  follow- 
on  testing. 
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Phase  H 

Synopsis.  Testing  in  the  second  phase  isdesigned  to  answer  the  question,  Ts  the  buyer  able 
to  select  the  correct  vendor  using  the  prototype  system?’  To  tl.ij  end,  DESC  selected  eight 
buyers  whose  daily  assignments  include  procurement  of  MilSpec  55 1 82  items.  However, 
after  the  testing  was  complete,  the  researcher  discovered  not  all  eight  buyers  selected  were 
familiar  with  the  procurement  of  MilSpec  55 1 82  items.  More  details  on  this  deviation  can 
be  found  later  in  the  chapter.  These  buyers  processed  the  same  purchase  requests  that  the 
panel  examined  in  Phase  1.  Their  selections  were  compared  to  that  of  the  panels'.  The  details 
of  the  tesf  follow. 

Testing  Phase  II  testing  commenced  on  23  July  1991.  On  that  morning,  thebuyc  .  s  received 
an  hour  briefing  concerning  this  pha.se  of  testing.  The  briefing  covered  the  overriding 
VASPP  concept  (provided  by  Mr.  Bill  Gates)  and  a  presentation  of  the  prototype  software 
(provided  by  the  researcher).  The  researcher  also  described  the  testing  procedure  that  would 
begin  that  afterntx^n. 

The  researcher  loaded  the  prototype  software  onto  the  computer  at  each  buyer's 
desk.  The  prototype  was  stai  ted  testf’d  w  ith  a  trial  entry  and  returned  lo  the  welcome  screen. 
Placed  on  each  desk  was  a  set  of  fifteen  purchase  requests.  Four  of  the  buvers.  selected 
arbitrarily,  were  provided  ti’e  purchase  requesi':  a  set  of  vendor  price  lists,  and  DESC  701 
forms,  used  for  manual  processing. 

The  other  four  buyers  were  provided  a  set  of  purchase  requests  (without  the  price 


lists  or  Form  701 )  for  prtKessmg  on  the  prototype  system.  Each  of  the  four  members  of 
a  group  was  given  the  same  purchase  requests  to  process.  All  purcha.se  requests  being 
processed  by  a  group  of  four  were  different  from  those  m  the  other  aroup. 


Phase  II  -  Part  1 . 


Manual  Prcx:essing.  To  perform  the  vendor  selection  process,  the  buyers 
repeat  the  process  used  in  Phase  I  for  manual  processing.  Once  the  part  number  of  the  item 
requested  is  located  on  the  purchase  request,  the  buyer  is  able  to  consult  the  vendor  price 
list.  If  the  part  number  appears  in  the  price  list,  the  appropriate  information  is  transcribed 
onto  DESC  Form  701. 

This  process  is  completed  for  all  known  vendors.  Having  identified  the  vendors 
listing  the  product  for  sale,  the  buyer  computed  the  extended  price  (priceofeach  item,  times 
the  quantity  required). 

The  buyer,  now  knowing  which  vendor(s)  can  supply  the  parts  at  the  lowest  cost, 
must  decide  which  vendor  is  best  qualified  to  receive  the  contract  award.  Before  this 
decision  can  be  made,  the  buyer  must  consult  several  historical  files  maintained  at  DESC 
regarding  each  vendor.  Once  the  file  review  is  completed,  the  buyer  possesses  the 
information  provided  by  the  vendor,  the  data  stored  on  file,  and  knowledge  gained  through 
experience.  The  buyer  can  now  make  the  final  award  decision. 

The  selected  vendor,  the  quantity  ordered,  and  the  extended  price  of  the  award  were 
then  recorded  on  the  Buyer  Selection  Form  attached  to  the  purchase  request  (Figure  5-4). 
In  addition,  the  buyers  recorded  the  purchase  request  processing  start  time  and  completion 
time.  If  an  interruption  occurred  during  the  analysis,  the  buyer  marked  the  appropriate 
block  on  the  attached  form.  Each  buyer  (using  the  manual  system)  processed  all  fifteen 
purchase  requests  in  this  manner. 

Automated  Processing.  The  four  buyers  using  the  automated  system 
received  a  set  of  fifteen  purchase  requests.  Each  set  contained  identical  purchase  requests. 
These  purchase  requests  were  unique  from  those  provided  to  the  buyer  performing  the 
manual  process. 
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FIGURE  5-4  -  BuYiiR  Si;i.i;('ti()n  Form 

Using  the  prototype,  the  buyer  was  prompted  to  enter  the  NSN  of  the  item  requested. 
Once  entered,  the  prototype  verified  the  validity  of  the  NSN  and  asked  the  buyer  to  input 
the  quantity  required.  These  two  data  elements  can  be  found  on  the  front  page  ot  the 
purchase  request  (Figure  5-5).  Next,  the  prototype  asked  the  buyer  for  the  required  delivery 
date;  found  on  the  last  page  of  the  purchase  request  (called  the  trailer)  (Figure  5-6).  Finally, 
the  user  indicated  whether  the  award  was  to  be  given  to  a  disadvantaged  business  (Set-A- 
Side). 

Having  entered  all  required  information,  the  system  interrogated  its  data  files  and 
displayed  the  unit  cost  screen.  This  screen  informs  the  buyer  which  vendors  supply  the  item 
required  as  well  as  the  minimum  quantity  of  the  product  (and  the  price  at  which  the  vendor 
offered  it  for  sale)  that  meets  or  exceeded  the  quantity  requested  on  the  purchase  request. 
The  buyer  was  now  able  to  switch  to  any  of  the  user  screens,  examining  the  data  presented, 
to  arrive  at  an  award  decision.  As  with  the  manual  process;  the  buyer  recorded  the  vendor 
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selected,  the  quantity  procured,  the  extended  price  of  the  contract,  and  the  time  required 
to  reach  an  award  decision,  on  the  Buyer  Selection  Form  attached  to  each  purchase  request. 

Throughout  this  process,  the  researcher  remained  in  the  area  of  the  buyers  to  answer 
any  questions  they  may  have  had. 

Phase  II  -  Part  2.  As  each  buyer  completed  their  respective  set  of  fifteen  purchase 
requests,  the  researcher  provided  them  with  a  second  set  of  fifteen  requests.  This  new  set 
was  identical  with  those  being  processed  by  the  other  group.  The  buyers  using  the  manual 
system  for  their  first  set,  now  used  the  prototype  system  to  process  the  new  set.  Those  buyers 
that  used  the  prototype  system,  now  used  the  manual  system  to  process  the  new  set.  As  in 
the  first  round,  the  buyers  recorded  the  vendor  selected,  the  quantity  procured,  extended 
price  of  the  award,  and  the  processing  start  and  stop  times. 

After  each  buyer  completed  processing  the  second  set  of  purchase  requests,  they 
received  a  questionnaire.  The  questionnaire  tried  to  capture  the  buyers  impression  of  the 
prototype,  as  tested,  and  the  course  that  future  developments  should  take.  The  buyers  were 
instructed  to  take  their  time  in  filling  out  the  questionnaire  and  return  it  the  following  day. 
The  comments  provided  by  the  buyers  can  be  found  in  Appendix  G. 

Results.  The  data  obtained  from  this  phase  of  testing  are  consolidated  and  presented  in  the 
following  tables  and  graphs.  The  data  are  divided  into  two  components,  the  first  being  the 
results  obtained  from  the  current  manual  system  for  processing  purchase  requests.  The 
second  contains  the  data  obtained  from  processing  the  purchase  requests  using  the  prototype. 

The  first  column  in  each  table  identifies  the  purchase  request  that  was  processed. 
Following  that  is  the  cage  code  (Vendor  Identification  Code)  of  the  vendor  selected,  the 
quantity  ordered,  the  price  paid,  and  the  number  of  people  who  made  this  selection.  The 
final  column.  Type  of  Error,  is  discussed  in  detail  later  in  this  chapter.  It  should  be  noted. 


5-\2 


the  first  row  of  each  section  (the  row  containing  the  purchase  request  number)  is  the  correct 
response,  as  determined  by  the  panel. 

In  Table  5-3,  the  #  indicates  where  the  buyers  misinterpreted  the  vendor  price  list. 
The  vendor  selected  does  not  offer  the  exact  part  as  requested  on  the  purchase  request.  Thus, 
these  entries  are  counted  as  errors.  Table  5-5  is  a  summary  of  the  errors  identified  in  this 
portion  of  the  testing. 

Table  5-4  lists  the  responses  obtained  from  the  automated  portion  of  the  testing.  Its 
format  is  the  same  as  that  for  Table  5-3,  Phase  II  Manual  Error  Results. 

The  Type  of  Error  symbols  found  in  Table  5-4  consist  of  the  following: 

1)  *  -  this  entry  matches  the  panel  selection. 

2)  &  -  this  error  is  a  result  of  transcribing  the  data  incorrectly.  It  counts  as  a 
reasonable  choice. 

3)  ^  -  indicates  the  purchase  requests  effected  by  the  incorrect  vendor  information 
entered  in  the  pricing  data  base. 

Table  5-6  is  a  summary  of  the  errors  identified  in  this  portion  of  the  testing. 

Error  Rate.  In  Tables  5-3  and  5-4,  the  final  column  indicates  the  type  of  error  made. 
The  panel  reviewed  each  selection  that  did  not  match  exactly  in  cage,  quantity,  and  price. 
They  made  the  determination  of  whether  the  selection  annotated  was  a  reasonable  alternate 
selection  or  if  it  was  an  error.  If  the  panel  felt  an  error  had  been  made,  they  tried  to  decide 
what  ted  to  the  incorrect  response. 

Figure  5-7  depicts  the  relationship  of  reasonable  responses  to  the  error  responses. 
In  the  manual  phase,  the  buyers  matched  the  panel  exactly  fifty  percent  of  the  time.  Twenty- 
eight  point  three  percent  of  the  responses  were  reasonable  alternate  choices.  The  manual 
method  of  making  the  vendor  selection  resulted  in  a  twenty-one  point  seven  percent  error 
rate. 
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TABLE  5-3 


Phase  II  Manual  Error  Results 


PHASE  II  -  MANUAL  ERROR 

RESULTS 

Purchase  Request 

Extended 

j 

i 

Number 

Cage 

Qntv 

Price 

n 

Type  Of  Error 

YPE91 191000882 

6S313 

149 

$163.90 

5 

* 

500 

$500.00 

1 

Reasonable  ' 

56856 

150 

$168.00 

1 

Error 

0BTU6 

149 

$178.80 

1 

Error 

YPE91 188000883 

7K545 

1000 

M  1 1 1 II 1  ■ 

1 

* 

528 

$126.72 

7 

Reasonable 

YPE91 195001056 

6S313 

$1 10.00 

5 

* 

100 

$153.00 

1 

Math  Error 

7K515 

100 

$115.00 

1 

Error 

0BTU6 

100 

$120.00 

1 

Error 

YPE91 195001053 

7K545 

lOOO 

$181.00 

3 

♦ 

809 

$155.33 

5 

Reasonable 

YPE91 188000892 

56856 

1 

66 

$118.80 

1 

Reasonable 

1 

6S313 

100 

$134.00 

4 

Error  [#) 

0BTU6 

100 

$151.00 

1 

Error 

100 

$389.00 

1 

Math  Error 

YPE91 191000875 

tmam 

KBl 

1 

200 

$45.00 

1 

Math  Error 

7K545 

500 

$119.00 

5 

Reasonable 

500 

$110.50 

1 

Math  Error 

YPE91 1880008S5 

6S313 

■migl 

5 

* 

56856 

64 

$102.40 

1 

Reasonable 

i 

100 

$115.00 

1 

Error 

7K545 

100 

$115.00 

1 

Error 

j YPE91 188000881 

7K545 

■a*!*! 

III  11 

5 

* 

165 

$66,01 

1 

Math  Error 

1 

500 

$144.00 

1 

Math  Error 

1 

6S313 

165 

$198.00 

1 

Error 

1 YPE91 188000894 

7K545 

■atai 

M  II 1 II 1  ■ 

6 

* 

1 

300 

$95.40 

1 

Math  Error 

500 

$1 16.00 

1 

Math  Error 

i YPE91 188000893 

6S313 

TO^T 

$60.00 

3 

* 

100 

$1 10.00 

1 

Math  Error 

i 

7K545 

500 

$120.00 

3 

Reasonable 

56856 

100 

$144.00 

1 

Error 

I YPE91 1510001 15 

7K545 

4191 

111  1  mi 

7 

♦ 

4191 

$808.86 

1 

Math  Error 

i YPE91 188000914 

■lisi 

$54.00 

6 

•» 

7K545 

500 

$159.00 

2 

Reasonable 

} YPE91 188000919 

6S313 

$45.00 

5 

♦ 

7K545 

500 

$118.00 

3 

Reasonable 

' YPE91 188000877 

7K545 

6 

331 

$107.91 

1 

Math  Error 

331 

$130.41 

1 

Math  Error 

YPE91 191000877 

7K545 

1000 

$216.00 

1 

1000 

$260.00 

1 

Math  Error 

642 

$148.94 

5 

Reasonable 

6S313 

642 

$148.94 

1 

Transcribe 
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TABLE  5-4 


Phase  II  Automated  Error  Results 


L  JPHASEJI 

-  AUl 

roM. 

ATEDJE 

JO 

R RESULTS 

Purchase  Request 

■■ 

■B 

Number 

n 

Type  Of  Error 

YPE91 177000268 

6S313 

i  100 

$53.00 

1  5  1 

i  * 

56856 

31 

$48.98 

'  3 

Reasonable 

YPE911 750001 78 

7K545 

6 

* 

6S313 

i  2 

Error 

YPE91 148000183 

6S313 

:  100 

$160.00 

;  7 

t  31 

$160.00 

!  1 

Transcribe(&) 

YPE91 157000145 

7K545 

6500 

$1,404.00 

*  (#) 

' 

7000 

$1,512.00 

Reasonable 

YPE91 146000673 

6S313 

100 

$45.00 

8 

1 YPE91 195001054 

6S313 

$144.10 

7 

* 

6S313 

$500.00 

1 

Reasonable 

YPE91 191000881 

7K545 

500 

$96.50 

2 

♦ 

1000 

$187.00 

1 

Error 

i 

i 

6S313 

500 

$90.00 

4 

Reasonable 

1 

268 

$90.00 

1 

Transcribe(&) 

YPE91 191000876 

7K545 

1000 

$187.00 

4 

♦ 

1 

6S313 

541 

$156.89 

4 

Reasonable 

YPE91 191000874 

6S313 

100 

$110.00 

3 

♦ 

1  1 

$47.50 

1 

Error 

56856 

25 

$47.50 

3 

Reasonable 

12 

$46.20 

1 

Error 

■ YPE9 11 83000890 

7K545 

1^ 

$144.00 

7 

$267.00 

1 

Error 

YPE91 188000887 

7K545 

1000 

$187.00 

8 

* 

! YPE91 151000352 

6S313 

100 

$53.00 

7 

* 

56856 

29 

$45.82 

1 

Reasonable 

YPE91 188000880 

6S313 

200 

$120.00 

4 

7K545 

200 

$120.00 

1 

Transcribel&l 

500 

$130.00 

2 

Reasonable 

1000  ' 

$250.00 

1 

Error 

YPE9n  88000879 

7K545 

2567 

$654.59 

0 

♦ 

3000 

$765.00 

8 

Reasonable 

YPE91 188000878 

56856 

58 

$92.80 

3 

*  [») 

6S313 

100  , 

$1 10.00 

5 

Reasonable 

5-15 


TABLE  5-5 


Phase  II  Manual  Summary  of  Responses 


[  PHASE  II  N 

SUMMARY  OF 

MANUAL 

RESPONSES 

Response  Categories 

Number  Observed 

Matched  Panel 

60 

Reasonable 

33 

Transcription 

1  1 

Math  Errors 

13 

Other  Errors 

13 

TABLE  5-6 

Phase  II  Automated  Summary  of  Responses 


PHASE  II  AUTOMATED 
SUMMARY  OF  RESPONSES 

f 

Response  Categories 

Number  Observed 

Matched  Panel 

1 

71 

Reasonable 

39 

'Transcription 

3 

Errors 

7 

FIGURE  5-7  -  Phase  II  Manual  vs  Autoviated  Error  Rate 


In  the  automated  phase,  the  buyers  matched  the  panel  fifty-nine  point  two  percent 
of  the  time.  Thirty-five  percent  of  the  responses  were  reasonable  alternate  choices.  This 
method  of  making  the  vendor  selection  resulted  in  a  five  point  eight  percent  error  rate. 

Using  the  prototype,  there  was  a  nine  point  two  percent  increase  in  buyer  selections 
that  matched  the  panel  exactly.  Conversely,  the  prototype  offered  a  fifteen  point  nine 
percent  reduction  in  errors. 

The  most  common  source  of  error  appears  to  be  math  related.  This  could  result  from 
either  misreading  the  vendor  price  lists  or  from  failing  to  perform  the  extended  price 
calculations  correctly.  As  the  prototype  performs  all  calculations,  math  errors  were  only 
identified  as  occurring  in  the  manual  process. 

A  second  problem  identified  was  transcribing  the  data  onto  the  response  form.  If 
two  of  the  three  categories  matched  the  panel  selection,  it  was  sometimes  possible  to  deduce 
the  remaining  data  element  was  copied  wrong.  For  example,  if  using  the  prototype  system, 
the  buyer  identified  the  correct  cage  code  and  quantity  but  the  pnce  was  incorrect,  it  could 
be  surmised  the  price  was  copied  incorrectly  from  the  monitor. 
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Analysis.  Using  Statistix  ‘s  AOV  procedure,  an  ANOVA  was  performed 
on  the  error  data  set  for  Phase  II  (Figure  5-8).  The  data  examined  are  found  in  Table  5- 
7.  The  null  hypothesis  being  examined  is  that  the  mean  of  the  differences  is  zero  (26:882). 
With  a  computed  p-value  of  0.0002,  the  null  hypothesis  can  be  rejected  at  the  ninety-nine 
percent  confidence  level.  In  other  words,  there  is  strong  statistical  evidence  to  suggest  there 
is  a  difference  in  the  number  of  errors  produced  by  the  buyers  using  the  two  methods  of 
vendor  selection. 


TABLE  5-7 
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STATISTIX  3.5 

ID:  PHASE  II  PROCESSING  ERRORS 


23  AUG  91,  17:35 


ONE  WAY  AOV  FOR  ERROR  =  SYSTEM 

SOURCE  DF  SS  MS  F  P 


BETWEEN  1  1.667  1.667  14.42  0.0002 

WITHIN  238  27.52  1.156E-01 

TOTAL  239  29.18 

CHI  SQ  DF  P 

BARTLETT'S  TEST  OF  . . 

EQUAL  VARIANCES  37.51  1  0.0000 

COCHRAN'S  Q  0.7604 

LARGEST  VAR  /  SMALLEST  VAR  3.174 

COMPONENT  OF  VARIANCE  FOR  BETWEEN  GROUPS  1.293E-02 
EFFECTIVE  CELL  SIZE  120.0 

SAMPLE  GROUP 

SYSTEM  MEAN  SIZE  STD  DEV 


1  2.250E-01  120  4.193E-01 

2  5.833E-02  120  2.354E-01 

TOTAL  1.417E-01  240  3.400E-01 

CASES  INCLUDED  240  MISSING  CASES  0 

f’lGURE  5-8  -  Phasi  II  Ehhok  Rah.  ANOVA  Ti.sr 


Figure  5-9  shows  the  number  of  errors  resulting  from  using  the  manual  system 
compared  to  the  errors  that  resulted  from  using  the  prototype.  The  horizontal  axis  shows  the 
number  of  errors  made  on  a  given  purchase  request.  The  vertical  axis  shows  the  number  of 
purchase  requests  that  contained  the  X-axis  quantity  of  errors.  From  this  graph,  it  can  be  seen 
the  highest  error  rate  for  any  purchase  request  processed  using  the  prototype  is  two.  (Two  of  the 
eight  buyers  recorded  incorrect  information.)  This  contrasts  to  the  manual  system.  There  was 
oneoutlierpurcha.se  request  with  seven  errors,  and  two  with  three  errors.  The  graph  also  shows 
using  the  prototype,  ten  purchase  requests  were  proces,sed  withou'  errorsby  all  buyers,  while  the 
manual  system  could  only  claim  four  error- free  requests. 
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PHASE  II  -  ERROR  RESPONSE 

MANUAL  vs  AUTOMATED 


0  1  2  Or  More 

Number  Of  Errors  Per  Purchase  Request 


FKiLIRE  5-9  -  Phasi  II  Ekkck  Rait 

Processing  Time.  The  buyers  documented  the  start  and  stop  times  for  each 
purchase  request  processed.  If  a  delay  occurred  during  processing,  the  response  form  was 
annotated  by  checking  the  delayed  box.  Those  requests  marked  delayed  were  not 
computed  in  the  total  processing  time.  The  total  time  taken  to  process  all  non-delayed 
purchase  requests  was  divided  by  the  number  of  non-delayed  requests,  to  attain  the 
average  time  required  to  process  each  reque.st. 

Analysis.  Figure  5-10  shows  the  descriptive  statistics  (derived  from  Table 
.5-8)  for  the  processing  lime  reported  by  the  buyers  to  process  the  manual  versus  the 
automated  portions  of  Phase  II  testing.  PHASfT2M  identifies  the  statistics  for  the  time 
required  to  process  the  request  using  the  manual  process.  The  mean  processing  time  is 
4.4  minutes.  There  is  ninety-five  percent  confidence  tlial  the  manual  processing  time  will 
lie  between  ,T9  and  4.9  minutes,  with  a  .standard  deviation  of  2..^  minutes. 


The  statistics  for  PHASE2A  was  generated  by  the  same  buyers,  but  this  time  using 
the  prototype.  The  results  of  this  phase  of  testing  are  as  follows.  The  mean  processing  time 
is  2.4  minutes.  There  is  ninety-five  percent  confidence  that  the  manual  processing  time  will 


lie  between  2.2  and  2.7,  with  a  standard  deviation  of  1.2  minutes. 


TABLE  5-8 


Phase  II  Processing  Time 


L _ 

Phase  II  Processing  Time 

111 

■ 

Buyer 

1 

3 

4 

5 

6 

7 

8 

a 

■■ 

5 

B 

B 

B 

B 

3 

3 

B 

o 

8 

5 

B 

B 

B 

B 

4 

B 

4 

5 

B 

B 

B 

5 

3  ’ 

B 

BB 

5 

5 

B 

B 

B 

Bfl 

5 

8 

B 

BB 

2 

10 

B 

B 

B 

B 

9 

2 

6 

mm 

B 

10 

3 

B 

2 

5 

B 

7 

BB 

B 

5 

2 

B 

2 

2 

•  5  ■ 

8 

D 

B 

10 

8 

B 

3 

3 

B 

9 

WM 

B 

8 

B 

5 

bI 

10 

BB 

B 

5 

B 

3 

B 

IB 

■■ 

10 

II 

5 

B 

5 

-» 

B 

B 

BB 

5 

5 

B 

B 

*> 

B 

13 

H 

3 

10 

■ 

3 

5 

5 

14 

WM 

B 

5 

'.0 

B 

B 

5 

15 

BB 

B 

5 

5 

B 

B 

5 

B 

3 

16 

mm 

B 

B 

5 

B 

B 

B 

B 

B 

17 

H 

B 

B 

B 

B 

B 

B 

B 

B 

i  IS 

H 

B 

B 

B 

B 

B 

B 

B 

3 

|l9 

2 

B 

5 

WM 

B 

2 

2 

B 

1 

20 

B 

5 

B 

B 

3 

5 

3 

!  21 

■ 

3 

B 

5 

■ 

B 

23 

m 

1 

II 

■ 

■ 

H 

■ 

!  24 

2 

2 

B 

B 

3 

3 

5 

B 

:  25 

1 

T 

B 

B 

B 

B 

i  26 

Bi 

B 

B 

4 

3 

B 

B 

5 

B 

!  27 

B 

B 

3 

1 

B 

B 

B 

28 

B 

B 

B 

3 

■» 

B 

3 

B 

B 

29 

■5 

B 

B 

B 

3 

B 

3 

B 

30 

B 

B 

B 

1 

B 

3 

B 

B 
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STATISTIX  3.5  30  AUG  91,  21:00 

ID:  PHASE  11  (MANUAL)  VS  PHASE  II  (AUTOMATED)  PROCESSING  TIMES 


DESCRIPTIVE  STATISTICS 


PHASE2M 

PHASE2A 

CASES 

99 

104 

LOWER  95.0%  C.I. 

3.940 

2.186 

MEAN 

4.404 

2.423 

UPPER  95.0%  C.I. 

4.368 

2.660 

S.D. 

2.325 

1.220 

S.E.  (MEAN) 

2.337E-01 

1.197E-I 

C.V. 

52.80 

50.36 

MINIMUM 

2.000 

1.000 

MEDIAN 

4.''^0 

2.000 

MAXIMUM 

11.00 

5.000 

FIGURE  5-10  -  Phase  II  Timino  Descriptive  S  rATiSTirs 

The  typical  processing  time  was  reduced  by  2.0  minutes  using  the  prototype.  This 
represents  an  approximate  forty-five  percent  reduction  in  processing  time.  Figure  5-11 
illustrates  the  processing  times  of  the  two  systems. 


FIGURE  5-1 1  —Phase  II  Proce.ssint.  Tivie.s 
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An  ANOVA  test  was  performed  comparing  the  processing  time  of  the  manual 
process  against  the  time  required  to  use  the  prototype  (Figure  5-12).  The  data  used  are  found 
in  Table  5-8. 

The  null  hypothesis  being  examined  is  that  the  mean  of  the  differences  is  zero 
(4:206).  With  a  computed  p-value  of  0.000,  the  null  hypothesis  can  be  rejected.  In  other 
words,  there  is  very  strong  statistical  evidence  to  suggest  there  is  a  significant  difference 
in  the  processing  times  of  the  two  systems. 


STATISTIX  3.5 

30  AUG  91,  21:23 

ID:  PHASE  n 

PROCESSING  TIMES 

ONE  WAY  AOV  FOR  TIME 

=  SYSTEM 

SOURCE  OF 

SS 

MS  F  P 

BETWEEN  1 

199.0 

199.0  58.55  0.0000 

WITHIN  201 

683.2 

3.399 

TOTAL  202 

882.3 

CHI  SQ  OF  P 

BARTLETT'S  TEST  OF  - 

. 

EQUAL  VARIANCES 

39.33  1  0.0000 

COCHRAN'S  0 

0.7840 

LARGEST  VAR  / 

SMALLEST  VAR  3.631 

COMPONENT  OF 

VARIANCE 

FOR  BETWEEN  GROUPS  1.929 

EFFECTIVE  CELL  SIZE 

101.4 

SAMPLE  GROUP 

SYSTEM  1 

MEAN 

SIZE  STD  DEV 

1  4 

.404 

99  2.325 

2  2 

.423 

104  1.220 

TOTAL  3 

.389 

203  1.844 

CASES  INCLUDED  203 

MISSING  CASES  37 

FIGURE  5-12  —  Phasi;  II  Proci.ssinc;  Timi,  ANOVA  Ti-.sr 
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Phase  III 


Synopsis.  The  third  and  final  phase  of  testing  was  conducted  on  July  25th.  This  test  sought 
to  answer  the  question  Ts  the  system  designed  such  that,  a  person  unfamiliar  with  the  items 
being  procured,  is  able  to  make  a  valid  vendor  selection  decision?’ 

Testing.  As  before,  eight  buyers,  selected  by  DESC,  received  an  orientation  briefing  in 
the  morning.  The  content  of  the  briefing  was  the  same  as  that  presented  to  the  buyers  in 
the  previous  phase.  The  prototype  software  was  loaded  onto  the  buyers  computer  systems 
during  the  lunch  break.  Placed  on  each  buyers  desk,  was  a  set  of  fifteen  purchase  requests. 
Each  set  was  identical,  and  was  the  same  as  used  in  the  automated  portion  of  Phase  II  testing. 

The  differences  in  this  phase  of  testing  versus  the  automated  portion  of  Phase  II  lie 
in  two  areas.  One,  the  buyers  chosen  to  participate  were  not  familiar  with  the  vendors  and 
products  of  the  MilSpec  55182  items.  Two.  the  buyers  only  processed  fifteen  purchase 
requests,  using  the  prototype  to  process  all  requests. 

As  before.  The  researcher  was  available  to  assist  the  buyers  during  the  testing 
portion. 

Results.  The  data  obtained  from  this  phase  of  testing  are  found  in  Table  5-9  and  the  types 
of  errors  encountered  are  summarized  in  Table  5-10. 

Error  Rate.  The  panel  reviewed  each  selection  that  did  not  match  exactly  in  cage, 
quantity,  and  price.  They  determined  if  the  selection  annotated  was  a  reasonable  alternate 
selection  or  if  it  was  an  error.  If  the  panel  felt  an  error  existed,  they  tried  to  decide  what 
led  to  the  incorrect  response.  A  indicates  the  response  was  reasonable.  A  '!'  indicates 
the  response  was  imrea.sonable.  A  indicates  a  perfect  match  to  the  panel  selection. 
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TABLE  5-9 


Phase  III  Results 


[  ^ _ PHASE  III  RESULTS 


Purchase  ^ 

Request  Number  Cage 

Qnty 

^Extended 

Price 

1  ' 

n  1 

j  ! 

Type  Of  Error 

YPE91 177000268 

6S313 

1  100 1 

$53.00 

5 

1  * 

56856 

31 

00 

00 

3 

1  Reasonable 

YPE91 175000178 

7K545 

500  ! 

$120.00 

4 

i  * 

i 

1 

6S313 

300 

1  $135.00 

1  3 

Error 

1 

30 

$135.00 

i  1 

Transcribed) 

YPE91 1480001 83 

6S313 

100 

'  $160.00 

1  8 

I  * 

1 

YPE91 157000145 

7K545 

6500 

I  $1404.00 

’  8 

!  « 

1 

YPE91 146000673 

6S313 

1  100 

$45.00 

!  7  J 

7K545 

:  500 

$118.00 

1 

Reasonable 

YPE91 195001054 

:6S313 

131 

$144.10 

7 

56856 

>  131 

$150.65 

1 

Wrong  Vendor 
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Analysis.  An  ANOVA  Test  was  performed  on  the  data  obtained  in  this  phase 
and  the  data  from  the  automated  portion  of  Phase  II  (Figure  5- 13).  The  data  examined  is  found 
in  Table  5-11.  As  before,  the  null  hypothesis  is  that  the  mean  of  the  differences  is  zero.  The 
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TABLE  5-10 


Phase  III  Summary  Of  Responses 


PHASE  III 

SUMMARY  OF  RESPONSES 


Response  Categories  Number  Observed 


Matched  Panel 
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TABLE  5-11 

Phase  II  &  III  Error  Data 


phase  II  vs  PHASE  III 

Error^Per  Purchase  Request 
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STATISTIX  3.5 

ID:  PHASE  II/III  PROCESSING  ERRORS 


30  AUG  91,  22:47 


ONE  WAY  AOV  FOR  ERROR  =  PHASE 

SOURCE  OF  SS  MS  F  P 

BETWEEN  1  1.667E-02  1.667E-02  0.27  0.6066 

WITHIN  238  14.92  6.268E-02 

TOTAL  239  14.93 

CHI  SO  OF  P 

BARTLETT'S  TEST  OF  . 

EQUAL  VARIANCES  1.61  1  0.2044 

COCHRAN'S  Q  0.5581 

LARGEST  VAR  /  SMALLEST  VAR  1.263 

COMPONENT  OF  VARIANCE  FOR  BETWEEN  GROUPS  -3.834E-04 
EFFECTIVE  CELL  SIZE  120.0 

SAMPLE  GROUP 

PHASE  MEAN  SIZE  STD  DEV 

FIGURE  5-13  -  Phase  II  &  III  Error  ANOVA  Test 

computed  p-value  is  0.6066,  therefore  the  null  cannot  be  rejected.  There  is  no  significant 
difference  in  the  error  data  obtained  from  those  people  not  familiar  with  the  MilSpec  55122 
items  when  compared  to  those  who  are  familiar  with  the  items. 

Figure  5-14  compares  the  error  rate  of  the  automated  portion  of  Phase  II  against  the 
results  of  Phase  Ill.  The  pie  graph  labeled  Phase  III  is  derived  from  Table  5-9. 

Interestingly,  the  buyers  without  prior  experience  in  this  area  showed  a  nine  point  one 
percent  increase  in  buyer  selections  that  matched  the  panel  exactly.  The  Phase  Ill  buyers  also 
experienced  an  increase  in  errors,  which ,  as  shown  by  the  above  ANO  ''A,  was  not  statistically 
different. 

Processing  Time.  As  before,  only  the  non-delayed  times  were  used  in  calculations. 
The  data  set  comparing  the  automated  times  from  Phase  II  and  those  from  Phase  III  are 
presented  in  Tabic  '  .T 
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TABLE  5-12 
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Analysis.  Figure  5-15  shows  the  descriptive  statistics  for  the  time  required 
for  the  buyers  to  process  the  Phase  II  automated  versus  the  Phase  III  automated  requests. 
Phase2  indicates  the  statistics  of  the  time  required  to  process  the  requests  by  users  familiar 
with  the  MilSpec  55182  procurement  process.  Phase3  indicates  the  statistics  of  the  time 
required  by  the  users  unfamiliar  with  this  process.  The  results  obtained  from  the  people 
who  were  not  familiar  with  the  products  and  vendors  used  in  the  evaluation  showed  similar 
results  compared  to  those  who  were. 

The  mean  processing  time  for  the  buyers  who  were  familiar  with  the  procurement 
process  is  2.4  minutes.  There  is  ninety-five  percent  confidence  that  the  processing  time  of 
those  familiar  with  the  products  and  vendors  will  lie  between  2.2  and  2.7  minutes.  The 
standard  deviation  is  1.2  minutes.  The  mean  processing  time  for  the  buyers  who  were 
unfamiliar  with  the  information  is  3.0  minutes.  There  is  ninety-five  percent  confidence  that 
their  processing  time  will  lie  between  2.7  and  3.3  minutes.  The  standard  deviation  is  1.5 
minutes.  Figure  5-16  illustrates  the  processing  times  of  the  two  groups. 


STATISTIX  3.5  23  AUG  91,  U:18 

ID:  PHASE  11  (AUrOMATED)  VS  PHASE  III  (AUTOMATED)  PROCESSING  TIMES 

DESCRIPTIVE  STATISTICS 


PHASE2 

PHASE3 

CASES 

lOA 

106 

LOWER  95.0%  C.I. 

2.186 

2.665 

MEAN 

2.A23 

2.962 

UPPER  95.0%  C.I. 

2.660 

3.258 

S.D. 

1.220 

1.526 

S.E.  (MEAN) 

1.197E-01 

1.496E-01 

C.V. 

50.36 

51.53 

MINIMUM 

1.000 

1.000 

median 

2.000 

3.000 

MAXIMUM 

5.000 

8.000 

FIGURE  5-IS  -  Phasi  I[  vs  Pham:  III  Pk(m  i.ssin<;  Timi  Di-.si  kii'itvi.  SiAnsncs 
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PROCESSING  TIMES 
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An  A  NOV  A  test  was  performed  comparing  the  processing  times  of  the  automated 
portion  of  Phase  II  against  the  time  required  by  the  buyers  in  Phase  III  (Figure  5-17).  This 
time  the  computed  p-value  is  0.0054.  There  is  evidence  to  indicate  a  difference  exists  in 
the  processing  times  of  the  two  groups. 

User  Comments 

The  comments  provided  by  the  users  were  very  encouraging.  The  major  responses 
to  each  question  are  summarized  below.  The  reader  is  invited  to  refer  to  Appendix  G  for 
a  complete  listing  of  all  comments  provided. 

Problems  incurred  while  u.sing  the  system  were  few.  The  most  significant  rests  in 
the  keys  that  are  active  to  the  user  at  the  Award  screen.  The  system  was  designed  to  enable 
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STATISTIX  3.5  23  AUG  91,  K:25 

ID:  PHASE  11  (AUTOMATED)  VS  PHASE  III  (AUTOMATED)  PROCESSING  TIMES 


ONE  WAY  AOV  FOR:  PHASE2  PHASE3 


SOURCE 

DF 

SS 

MS 

F  P 

BETWEEN 

1 

15.08  15 

.08 

7.90  0.0054 

WITHIN 

206 

393.2  1. 

909 

TOTAL 

207 

408.3 

CHI  SQ 

DF 

P 

BARTLETT 

'S  TEST  OF  . 

EQUAL 

VARIANCES  5.08 

1 

0.0242 

COCHRAN' 

S  Q 

0.6099 

LARGEST 

VAR  / 

SMALLEST  VAR 

1.564 

COMPONENT  OF  VARIANCE  FOR  BETWEEN  GROUPS  1.266E-01 
EFFECTIVE  CELL  SIZE  104.0 


SAMPLE  GROUP 


VARIABLE 

MEAN 

SIZE 

STD  1 

PHASE2 

2.423 

104 

1.220 

PHASE3 

2.962 

104 

1.526 

TOTAL 

2.692 

208 

1.382 

CASES  INCLUDED  208  MISSING  CASES  32 


FIGURE  5-17  -  Pham  II/I([  Timi  Comi’akison  ANOVA  Ti.st 


the  user  to  press  virtually  any  key  when  completed  with  this  screen  and  return  to  the  System 
Information  screen.  It  is  apparently  ‘too  easy’  to  exit  the  Award  screen  prematurely. 

Irrelevant  information  provided  by  the  system  was  the  next  area  discussed.  A 
majority  of  the  buyers  thought  the  required  delivery  date  was  over  emphasized.  It  appears 
the  RDD  date  given  on  the  purchase  request  provides  little  influence  in  the  award  decision. 


5-31 


Several  different  comments  were  offered  for  additional  information  that  the 
prototype  could/should  provide.  The  most  common  suggestions  are:  identifying  the 
manufacture  of  the  part  being  offered  by  the  vendor;  packing  data;  location  and  terms  of 
item  inspection;  vendor  points  of  contact;  and  the  inclusion  of  the  quantity  of  the  last  buy 
in  the  historical  information  section.  (The  quantity  of  the  last  procurement  is  tracked  by 
the  prototype.  It  was  an  oversight  that  it  was  not  included  on  the  user  screens.) 

Responses  to  system  future  enhancements  paralleled  those  for  additional  informa¬ 
tion.  One  forward  looking  individual  suggested  the  system  be  designed  to  accommodate 
the  automatic  printing  of  the  DESC  Form  800  after  the  award  decision  is  made. 

The  last  question  allowed  the  user  to  provide  comments  on  the  usefulness  of  the 
system.  The  responses  here  range  from  cautious  optimism  to  full  endorsement  of  the 
system.  It  is  quite  evident  the  buyers  view  the  prototype  as  a  significant  improvement  over 
the  current  method  of  vendor  selection. 

Initial  Conclusions 

There  is  strong  evidence  implying  the  prototype  can  present  the  correct  information 
to  the  buyer  and  the  buyer  can  successfully  use  the  prototype  to  make  a  responsive  award 
decision.  To  arrive  at  this  inference,  prototype  testing  was  accomplished  in  three  phases. 
The  first  addressed  whether  the  prototype  presented  the  correct  information.  The  second 
phase  demonstrated  the  prototype  produced  quicker  and  more  consistent  results.  The  third 
phase  examined  its  usability  to  buyers  unfamiliar  with  the  products  and/or  vendors. 

The  comments  provided  by  the  buyers  regarding  the  utility  of  the  prototype  are  very 
Positive.  There  is  commonality  in  their  replies  that  leads  one  to  believe  the  prototype 
significantly  enhances  the  current  vendor  selection  method. 

The  positive  results  thus  far  must  be  tempered  as  the  composition  of  the  Phase  II 
test  group  was  not  as  intended.  This  caveat  is  discussed  at  length  in  the  next  section. 
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Short  Comings 


After  review  of  the  data,  two  problems  were  identified  in  the  testing  process. 

PR  Testing- 

Problem.  A  weakness  was  recognized  involving  the  purchase  requests.  The  fifteen 
requests  processed  manually  were  never  processed  using  the  prototype.  The  possibility 
exists  that  the  improvements  observed  in  the  error  rate  and  processing  times  of  the  prototype 
could  be  explained  by  the  accumulated  difference  in  complexity  of  the  purchase  requests 
in  each  group. 

Correction.  In  an  attempt  to  correct  this  deficiency,  each  panel  member  was  asked 
to  rank  each  purchase  request  according  to  its  complexity.  The  panel  members  were 
provided  with  a  copy  of  the  thirty  purchase  requests,  the  vendor  price  lists,  and  the  70 1  forms 
they  completed  in  Phase  I  of  the  testing.  Using  a  five  level  scale,  the  buyers  indicated  their 
opinions  regarding  the  complexity  of  the  purchase  requests.  The  form  found  in  Figure  5- 
18  was  used  to  record  their  resfxmses.  No  purchase  request  was  scored  more  difficult  than 
‘Easy’.  Table  5-13  displays  the  results  of  their  efforts.  The  first  fifteen  purchase  requests 
listed  on  the  form  were  processed  in  Phase  II  using  the  manual  method  of  vendor  selection. 
The  last  fifteen  purchase  requests  were  processed  using  the  prototype.  The  panel  was  not 
informed  of  this  grouping. 

Table  5-14  shows  the  average  difficulty  assigned  to  each  purchase  request. 
'Method’  defines  the  system  used  to  process  the  purchase  requests  in  Phase  II  of  the  testing. 
A  '  r  represents  the  manual  process  was  used,  and  a  '2'  represents  the  prototype  system 
was  used.  'Purchase  Request'  tracks  the  thirty  requests  processed  on  either  system.  'Panel 
Member  1  ’  identifies  the  responses  provided  by  one  panel  member  regarding  the  degree  of 
difficulty  of  each  purchase  request  evaluated.  A  corresponds  to  'Very  Easv'.  '2' 
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Purchase  Request 
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TABLE  5-13 


Purchase  Request  Degree  of  Difficulty  Responses 
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TABLE  5-14 


Purchase  Request  Average  Degree  of  Difficulty 

Purchase  Request 


Average  Degree  of  Difficulty 


corresponds  to  ‘Easy’,  and  so  on  to  ‘5’  which  corresponds  to  ‘Very  Difficult’.  ‘Panel 
Member  2’  identifies  the  responses  provided  by  the  other  panel  member.  The  final  column, 
‘Average’  represents  the  average  degree  of  difficulty  assigned  to  each  purchase  request.  It 
was  derived  by  combining  the  points  assigned  to  each  request  and  dividing  the  result  by  two. 

Results.  Figure  5-19  depicts  the  results  of  the  ANOVA  test  performed  on  the  table 
data.  The  p- value  of  the  between  samples  errors  is  0.3987.  There  is  not  significant  statistical 
evidence  to  indicate  the  purchase  requests  processed  in  each  group  differ  in  complexity.  The 
null  hypothesis  (the  difficulty  level  of  the  two  samples  are  equal)  cannot  be  rejected  above 


STATISTIX 

3.5 

31  AUG  91,  0:01 

ID:  PURCHASE 

REQUEST 

DEGREE  OF  DIFFICULTY 

ONE  WAY  AOV  FOR  SCORE 

=  METHOD 

SOURCE 

DF 

SS 

MS  F  P 

BETWEEN 

1 

1.500E 

-01  1.500E-01  0.72  0.3987 

WITHIN 

58 

12.03 

2.075E-01 

TOTAL 

59 

12.18 

CHI  SQ  DF  P 

BARTLETT' 

S  TEST  OF  - 

. 

EQUAL 

VARIANCES 

0.33  1  0.5629 

COCHRAN'S 

Q 

0.5540 

LARGEST  VAR  / 

SMALLEST  VAR  1.242 

COHPONENT 

OF 

VARIANCE 

FOR  BETWEEN  GROUPS  -1.916E-03 

EFFECTIVE 

CELL  SIZE 

30.0 

SAMPLE  GROUP 

METHOD 

MEAN 

SIZE  STD  DEV 

1 

1 

.333 

30  4.795E  01 

2 

1 

.233 

30  4.302E-01 

TOTAL 

1 

.283 

60  4.555E-01 

CASES  INCLUDED  60 

MISSING  CASES  0 

FIGURE  5-19  -  Pi  RCHASi,  Rign.si  DixiKi.i'.  m-  Dnncn.TY  ANOVA  Ti.st 
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the  sixty  percent  confidence  level.  Therefore  the  difference  between  the  manual  and 
automated  results  cannot  be  explained  by  differences  in  the  complexity  of  the  purchase 
requests.  The  purchase  requests  can  be  considered  equal  for  both  the  manual  and  automated 
approaches. 

Buyers  Selected  (Phase  II  Impact!. 

Problem.  For  the  Phase  II  testing,  DESC  was  requested  to  provide  eight  buyers 
familiar  with  processing  MilSpec  55 1 82  price  listed  items.  After  the  testing  was  completed, 
it  was  learned  by  the  researcher  that  not  all  eight  buyers  were  familiar  with  the  items  as 
requested.  A  buyer  not  being  familiar  with  the  current  vendor  selection  process  could 
explain  some  of  the  improvements  observed  in  the  error  rate  and  processing  times  of  the 
prototype.  Due  to  the  anonymity  granted  to  the  buyers,  it  was  not  possible  to  identify  which 
buyer  generated  which  set  of  data. 

Correction. 

Error  Rate  The  data  obtained  from  this  Phase  of  testing  was  re-evaluated, 
examining  the  errors  made  by  each  buyer.  Figure  5-20  shows  the  errors  made  by  each  buyer 
for  both  portions  of  the  test.  It  appears  buyers  one,  three,  and  seven  made  significantly  more 
errors  than  the  other  buyers.  This  theory  was  tested  using  the  Sfarisrix  one-way  AOV  test. 
A  computed  p-value  of  0.0015  confirms  a  significant  difference  exists  in  the  error  rates  of 
the  buyers  (Figure  5-21). 

To  determine  which  buyers  were  significantly  different,  Tukey's  comparison  of 
means  test  was  used.  Tukey  was  selected  because  “It  controls  the  expierimentwise  error 
rate  yet  still  retains  good  power”  (4:144).  The  results  of  this  test  show  three  buyer  groups 
in  which  the  means  are  not  significantly  different  from  one  another  at  the  0.05  level  (Figure 
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FIGURE  5-20  -  Ekk(ir.s  By  Bi  yi  r 


5-22).  An  A  NOVA  test  was  performed  for  each  group,  using  the  Phase  II  error  data  from 
Table  5-7.  This  series  of  tests  is  looking  for  a  group  of  buyers  which  do  not  experience 
a  significant  reduction  in  error  rates  by  using  the  prototype.  After  examination  of  the 
ANOVA  results  (Figures  5-23  through  5-25)  it  can  be  concluded,  that  each  group,  whether 
experienced  or  not,  each  group  is  experiencing  a  significant  reduction  (at  the  ninety-nine 
percent  confidence  level)  in  error  rates  by  using  the  prototype. 

PrcKessing  Time.  The  timing  data  from  Phase  II  were  re-evaluated, 
excluding  buyers  based  on  Tukey's  test  comparing  the  buyers  mean  time  required  to  process 
the  purchase  requests  (Figure  5-26).  Based  on  mean  processing  time,  there  is  no  group  of 
buyers  that  did  not  experience  a  significant  improvement  in  the  purchase  request  processing 
time  when  using  the  prototype.  Statistically,  there  is  over  a  ninety-nine  percent  confidence 
level  that  the  processing  time  of  the  two  methods  are  different  (Figure  5-27  through  5-32). 


STATISTIX  3.5 

ID:  PHASE  II  PROCESSING  ERRORS 


23  AUG  91,  16:41 


ONE  WAY  AOV  FOR  ERROR  =  BUYER 


SOURCE 

DF  SS 

MS  F  P 

BETWEEN 

7  2.783 

3. 

976E-01  3.49  0.0015 

WITHIN 

232  26.40 

1. 

138E-01 

TOTAL 

239  29.18 

CHI  SO 

OF  P 

BARTLETT 

'S  TEST  OF  -- 

— 

. 

EQUAL 

VARIANCES  44.51 

7  0.0000 

COCHRAN' 

S  0 

0.2525 

LARGEST 

VAR  /  SMALLEST 

VAR 

6.897 

COMPONENT  OF  VARIANCE 

FOR  BETWEEN  GROUPS  9.461E-03 

EFFECTIVE  CELL  SIZE 

30.0 

SAMPLE  GROUP 

BUYER 

MEAN 

SIZE 

STD  DEV 

1 

1.667E-01 

30 

3.790E-01 

2 

6.667E-02 

30 

2.537E-01 

3 

3.333E-01 

30 

4.795E-01 

4 

3.333E-02 

30 

1.826E-01 

5 

1.000E-01 

30 

3.051E-01 

6 

6.667E-02 

30 

2.537E-01 

7 

3.000E-01 

30 

4.661E-01 

8 

6 . 66 7E ■ 02 

30 

2.537E-01 

TOTAL 

1 .417E-01 

240 

3.373E-01 

CASES  INCLUDED  240 

MISSING  CASES  0 

FIGURE  5-21  -  ANOVA  Ti.sr  Bi  yi  h  Ekkok  Rati,  CovirAKisoN 
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STATISTIX 

3.5 

31  AUG  91,  0:48 

ID:  PHASE 

II  PROCESSING  ERRORS  (ANALYSI2ED  BY  BUYER) 

TUKEY  (HSO)  PAIRWISE  COHPARISQNS  OF  MEANS  OF  ERROR  BY  BUYER 

HOMOGENEOUS 

BUYER 

MEAN 

GROUPS 

3 

3.333E-01 

I 

7 

3.000E-01 

I  I 

1 

1.667E-01 

I  I  I 

5 

1 .OOOE-01 

I  I  I 

2 

6.667E-02 

6 

6.667E-02 

a 

6.667E-02 

<* 

3.333E-02 

....  I 

THERE  ARE 

3  GROUPS  IN 

WHICH  THE  MEANS  ARE 

NOT  SIGNIFICANTLY  DIFFERENT  FROM  ONE  ANOTHER. 

CRITICAL 

Q  VALUE 

4.285  REJECTION  LEVEL  0.050 

CRITICAL 

VALUE  FOR  COMPARISON  2.6391E-01 

STANDARD 

ERROR  FOR  COMPARISON  a.7099E-02 

Fir.fRi':  5-22  -  Ti  ki:y  Comi’aw-son  Of  Bi  yfr  Error  Ratj-:s 


Results.  The  Phase  II  data  was  re-examined  looking  for  any  indication  that 
inexperienced  buyers  could  have  affected  the  test  results.  An  analysis  of  the  buyer’s  mean 
scores  was  used  to  categorize  them  in  further  testing.  (Inexperienced  buyers  should  show 
a  statistically  different  mean  error  rate  and  processing  from  the  experienced  buyers.)  An 
ANOVA  test  was  performed  on  each  group.  No  evidence  was  produced  to  indicate  the 
differences  in  error  rates  and  processing  times  recorded  using  the  prototype,  was  due  to  the 
different  experience  levels  of  the  buyers. 
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STATISTIX  3.5  31  AUG  91,  1:11 

ID:  PHASE  II  PROCESSING  ERRORS  (BUYERS  2,  4,  6,  AND  8  REMOVED) 

ONE  WAY  AOV  FOR  ERROR  =  SYSTEM 


SOURCE 

DF 

SS 

MS 

F  P 

BETWEEN 

1 

1.408  1 

.408 

8.51  0.0042 

WITHIN 

118 

19.52  1 

.654E-01 

TOTAL 

119 

20.92 

CHI  SQ 

DF 

P 

BARTLETT 

■S  TEST  OF  . - 

EQUAL 

VARIANCES  8.43 

1 

0.0037 

COCHRAN' 

S  0 

0.6832 

LARGEST 

VAR  / 

SMALLEST  VAR 

COMPONENT  OF  VARIANCE  FOP  BETWEEN  GROUPS  2.072E-02 
EFFECTIVE  CELL  SI2E  60.0 


SYSTEM 

MEAN 

SAMPLE 

SIZE 

GROUP 

STD  DEV 

1 

3.333E-01 

60 

4.754E-01 

2 

1.167E-01 

60 

3.237E-01 

TOTAL 

2.250E-01 

120 

4.067E-01 

CASES  INCLUDED  120  MISSING  CASES  0 


FIGURE  5-23  Pha.si  li  Si  mCkdi  i’  Om.  Andva  Comparison 
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STATIST  IX 

3.5 

31  AUG  91, 

1:08 

ID:  PHASE 

II 

PROCESS  IN 

G  ERRORS  (BUYERS  3  AND  4  REMOVED) 

ONE  UAY  AOV  FOR  ERROR 

=  SYSTEM 

SOURCE 

DF 

SS 

MS  F  P 

BETWEEN 

1 

9.389E- 

01  9.389E-01  8.74  0.0035 

WITHIN 

178 

19.12 

1.074E-01 

TOTAL 

179 

20.06 

CHI  SQ  DF  P 

BARTLETT' 

S  TEST  OF  -- 

. - . 

EQUAL 

VARIANCES  26.19  1  0.0000 

COCHRAN'S 

0 

0.7531 

LARGEST  VAR  / 

SMALLEST 

VAR  3.049 

COHPONENT 

OF 

VARIANCE 

FOR  BETWEEN  GROUPS  9.238E-03 

EFFECTIVE 

CELL  SIZE 

90.0 

SAMPLE  GROUP 

SYSTEM 

MEAN 

SIZE  STD  DEV 

1 

2 

.OOOE-01 

90  4.022E-01 

2 

5 

.556E-02 

90  2.303E-01 

TOTAL 

1 

.278E-01 

180  3.278E-01 

CASES  INCLUDED  180 

MISSING  CASES  0 

FIGURE  5-24  -  Phasi.  II  Si  iiCkoi  i' Two  ANOVA  Comparison 


5-4,1 


STATISTIX  3.5 

ID:  PHASE  II  PROCESSING  ERRORS  (BUYERS  3  AND  7  REMOVED) 


31  AUG  91,  1:05 


ONE  WAY  AOV  FOR  ERROR  =  SYSTEM 

SOURCE  DF  SS  MS  F  P 


BETWEEN  1  6.722E-01  6.722E-01  9.15  0.0029 

WITHIN  178  13.08  7.347E-02 

TOTAL  179  13.75 

CHI  SQ  DF  P 

BARTLETT'S  TEST  OF  . 

EQUAL  VARIANCES  59.82  1  0.0000 

COCHRAN'S  Q  0.8505 

LARGEST  VAR  /  SMALLEST  VAR  5.688 

COMPONENT  OF  VARIANCE  FOR  BETWEEN  GROUPS  6.653E-03 
effective  cell  Si:t  90.0 


SYST'  1 

MEAN 

SAMPLE 

SIZE 

GROUP 

STD  DEV 

1 

1.444E-01 

90 

3.535E01 

2 

2.222E-02 

90 

1.482E-01 

TOTAL 

8.333E-02 

180 

2.711E-01 

CASES  INCLUDED  180  MISSING  CASES  0 

FIGURE  5-25  --  Pham  II  Si  hGhci  p  Thki  p,  ANOVA  Comparison 
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STATISTIX  3.5 

ID:  Phase  II  Processing  Times 


31  AUG  91,  1:33 


TUKEY  (HSO)  PAIRWISE  COMPARISONS  OF  MEANS  Of  TIME  BY  BUYER 


BUYER 

MEAN 

7 

3 

2 

6 

1 

8 

7 

A.  706 

3 

A. 615 

0.21 

2 

A.  222 

1.15 

1.05 

6 

3.A07 

3.08 

3.23 

2.20 

1 

3.222 

3.52 

3.72 

2.70 

0.50 

8 

2.6A3 

A. 92* 

5.31* 

A.  30* 

2.08 

1.58 

U 

2.565 

A. 91* 

5.26* 

A. 28 

2.18 

1.70 

0.20 

5 

2.21A 

5.95* 

6.A7* 

5  A6* 

3.25 

2.7A 

1.18 

BUYER 

MEAN 

A 

A 

2.565 

5 

2.21A 

0.92 

CRITICAL 

Q  VALUE  A. 

285  REJECTION  LEVEL 

0.050 

STANDARD 

ERRORS  AND 

CRITICAL 

VALUES  OF  DIFFERENCES 

VARY  BETWEEN  COMPARISONS  BECAUSE  OF  UNEQUAL  SAMPLE  SIZES. 


FIGURE  5-26  -  Ti  ki  y  Comparison  Oi  Proci.ssi.vi  Time  Mpjyn.s 
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STATISTIX  3.5  31  AUG  91, 

ID:  Phase  II  Processing  Times  (Buyers  4,  5,  and  8  Removed) 

ONE  WAY  AOV  FOR  TIME  =  SYSTEM 


SOURCE 

OF 

SS 

MS 

F  P 

BETWEEN 

1 

203.8  203.8 

53.02  0.0000 

WITHIN 

122 

469.1  3 

.845 

TOTAL 

123 

672.9 

CHI  SO 

OF 

P 

BARTLETT 

■S  TEST  OF  - 

EQUAL 

VARIANCES  18.50 

1 

0.0000 

COCHRAN' 

S  Q 

0.7555 

LARGEST 

VAR  / 

SMALLEST  VAR 

3.089 

COMPONENT  Of  VARIANCE  FOR  BETWEEN  GROUPS  3.229 
EFFECTIVE  CELL  SIZE  61.9 


SYSTEM 

MEAN 

SAMPLE 

SIZE 

GROUP 

STD  DE\ 

1 

5,300 

60 

2.431 

2 

2.734 

64 

1.383 

TOTAL 

3.976 

124 

1.961 

CASES  INCLUDED  124 

MISSING  CASES  26 

FIGURE  5-27  -  Pham  II  Sihm  i  Oni  Pkoci.ssin'i  Timi.s  .ANOVA 


1:41 
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STATISTIX  3.5 

10:  Phase  II  Processtnij  Titties  (Buyers  4,  5,  7,  and  8  Removed) 


31  AUG  91,  1:44 


ONE  WAY 

AOV  FOR  TIME  = 

SYSTEM 

SOURCE 

OF 

ss 

MS 

F 

BETUEEN 

1 

240.7 

240.7 

65.77 

WITHIN 

105 

384.2 

3.659 

TOTAL 

106 

624.9 

CHI 

SQ  DF 

P 

BARTLETT 

'S  TEST  OF  --- 

. 

— 

EQUAL 

VARIANCES  26 

.29  1 

0.0000 

COCHRAN' 

S  Q 

0.8127 

LARGEST 

VAR  / 

SMALLEST 

VAR  4.338 

COMPONENT  OF  VARIANCE  FOR  BETUEEN  GROUPS  4.440 
EFFECTIVE  CELL  SIZE  53.4 


SAMPLE 

GROUP 

SYSTEM 

MEAN 

SIZE 

STD  DEV 

1 

5.431 

51 

2.476 

2 

2,429 

56 

1.189 

TOTAL 

3.860 

107 

1.913 

CASES  INCLUDED  107  MISSING  CASES  13 


FIGliRE  5-28  --  Phasi.  II  Si  bm  i  Two  Pkoi  i.ssino  Timi.s  ANOVA 
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STA, ISTIX 

3.5 

31  AUG  91, 

1:51 

I  Phase 

11  Processing 

Times  (Buyers  3,  5, 

7,  and  8  Removed) 

ONE  WAY  AOV  FOR  TIME  = 

S.oTEH 

SOURCE 

OF  SS 

MS  F 

P 

BETWEEN 

1  187.5 

187.5  65.69 

0.0000 

WITHIN 

102  291.1 

2.854 

TOTAL 

103  478.6 

CHI 

SO  DF  P 

BARTLETT' 

S  TEST  OF  --- 

. 

EQUAL 

VARIANCES  26 

.56  1  0.0000 

COCHRAN'S 

Q 

0.B178 

LARGEST  VAR  /  SMALLEST 

VAR  4.488 

COMPONENT 

OF  VARIANCE  FOR  BETWEEN  GROUPS  3 

.556 

EFFECTIVE 

CELL  SIZE 

51.9 

SAMPLE  GROUP 

SYSTEM 

MEAN 

SIZE  STD  DEV 

1 

4,780 

50  ?  .88 

2 

2.093 

54  1.033 

TOTAL 

3.385 

104  1.689 

CASES  INCLUDED  104  MISSING  CASES  16 


FIGURE  5-29  -  Phasi-  II  Si  nsi  i  Thru  PKoci:s.siN(i  Ti.mils  ANOVA 
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STATIST  IX  3.5 

ID:  Phase  II  Processing  Times  (Buyers  2,  3,  and  7  Removed) 


31  AUG  91,  2:03 


ONE  WAY  AOV  FOR  TIME  =  SYSTEM 


SOURCE 

OF 

SS 

MS 

F  P 

BETWEEN 

1 

69.96  69.96 

50.26  0.0000 

WITHIN 

131 

182.3  1. 

392 

TOTAL 

132 

252.3 

CHI  SQ 

OF 

P 

BARTLETT 

'S  TEST  OF  . - 

— 

EQUAL 

VARIANCES  28.68 

1 

0.0000 

COCHRAN' 

S  Q 

0.7976 

LARGEST 

VAR  / 

SMALLEST  VAR 

3.940 

COMPONENT  OF  VARIANCE  FOR  BETWEEN  GROUPS  1.032 
EFFECTIVE  CELL  SIZE  66.5 


SYSTEM 

MEAN 

SAMPLE 

SIZE 

GROUP 

STD  DEV 

1 

3.554 

65 

1.500 

2 

2.103 

68 

7.559E-01 

TOTAL 

2.812 

133 

1.180 

CASES  INCLUDED  133  MISSING  CASES  17 


FIGURE  5-30  —  Phasi:  II  Si  bsli  Four  Pkoci.ssinu  Timi-.s  ,\N0VA 


STATISTIX  3.5 

ID;  Phase  II  Processing  Times  (Buyers  1,  2,  3,  6,  and  7  Removed) 


31  AUG  91 


ONE  UAY  AOV 

FOR  TIME 

=  SYSTEM 

SOURCE  OF 

SS 

MS 

F  P 

-  _  _ 

BETWEEN  1 

23.92 

23.92 

24.32  0.0000 

WITHIN  77 

75.75 

0.984 

TOTAL  78 

99.67 

CHI  SO  DF 

P 

BARTLETT'S  TEST  OF  - 

. 

. 

EQUAL  VARIANCES 

14.75  1 

0.0001 

COCHRAN'S  0 

0.7830 

LARGEST  VAR 

/  SMALLEST  VAR  3.608 

COMPONENT  OF 

VARIANCE 

FOR  BETWEEN  GROUPS  5.808E-01 

EFFECTIVE  CELL  SIZE 

39,5 

SAMPLE 

GROUP 

SYSTEM 

MEAN 

SIZE 

STD  DEV 

1 

3.026 

39 

1.246 

2 

1.925 

40 

6.558E-01 

TOTAL 

2.468 

79 

0.992 

CASES  INCLUDED  79 

MISSING  CASES  11 

FIGURE  5-31  -  Phasi  II  Si  msi  r  Fivi  Pkoci.ssimi  Timi.s  ANOVA 
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STATISTIX  3.5  31  AUG  91,  2:17 

ID:  Phase  II  Processing  Times  (Buyers  1,  2,  3,  4,  6,  and  7  Removed) 


ONE  WAY  AOV  FOR  TIME  =  SYSTEM 


SOURCE 

OF 

SS 

MS 

BETWEEN 

1 

14.00 

14.00 

WITHIN 

54 

57.71 

1.069 

TOTAL 

55 

71.71 

F  P 

13.10  0.0007 


CHI  SO  OF  P 

BARTLETT'S  TEST  OF  . - . 

EQUAL  VARIANCES  15.07  1  0.0001 

COCHRAN'S  Q  0.8292 

LARGEST  VAR  /  SMALLEST  VAR  4.855 

COMPONENT  OF  VARIANCE  FOR  BETWEEN  GROUPS  4.618E-01 
EFFECTIVE  CELL  SIZE  28.0 


SYSTEM 

MEAN 

SAMPLE 

SIZE 

GR(XJP 

STD  DEV 

1 

2.929 

28 

1.331 

2 

1.929  . 

28 

.6.042E-01 

TOTAL 

2.429 

56 

1.034 

CASES  INCLUDED  56 

MISSING 

CASES  4 

FIGURE  5-32  -  Phase  II  Si  iisin  Six  PRori.ssiNu  Timils  ANOVA 
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Buyers  Selected  (Phase  III  Impact). 

Problem.  The  purpose  of  Phase  III  testing  was  to  determine  if  the  system  could  assist 
buyers,  not  familiar  with  the  items  being  procured,  in  making  a  better  and  more  timely  award 
decision.  Without  the  benefit  of  having  a  control  group,  comprised  in  its  entirety  of 
individuals  knowledgeable  in  the  procurement  of  the  items  being  examined,  the  intended 
goal  of  Phase  III  cannot  be  directly  reached. 

Correction.  The  researcher,  through  earlier  interviews,  knows  at  least  two  of  the 
Phase  II  buyers  are  knowledgeable  in  the  procurement  of  MilSpec  55 1 82  items.  However, 
because  of  anonymity,  the  control  number  assigned  to  those  buyers  during  testing  is 
unknown.  Conventional  wisdom  dictates  those  buyers  most  familiar  with  the  items,  should 
generate  the  best  scores.  This  reasoning  will  also  provide  the  most  stringent  criteria  against 
which  to  compare  the  buyers  participating  in  Phase  III  testing. 

Error  Rate.  The  number  of  errors  made  by  each  buyer  in  Phase  II  testing 
were  reviewed.  The  two  buyers  having  the  fewest  errors,  a  composite  of  manual  and 
automated  scores,  were  used  in  a  nonparametric  analysis  with  the  eight  buyers  of  Phase  111. 
A  statistical  test  providing  a  nonparametric  .ANOVA  test  is  the  Kruskal-Wallis  One  Way 
AOV  (4:222). 

From  the  combined  stages  of  Phase  II  testing,  buyer  Four  had  one  error  and  buyers 
Two.  Six,  and  Eight  had  two  errors.  Tukey's  comparison  of  means  of  errors  for  Phase  II 
buyers  was  performed  with  buyers  Two,  Six,  and  Eight  (Figure  5-33).  All  three  of  these 
buyers  error  rates  were  not  significantly  different  from  each  other.  Therefore,  as  it  is 
statistically  impossible  to  differentiate  between  the  three  buyers,  the  Phase  111  results  will 
be  compared  only  to  buyer  Four.  Figure  5-34  shows  the  results  of  this  ANOVA  test.  With 
a  p-value  of  0.2757,  there  can  be  no  more  than  seventy-two  percent  confidence  that  the 
inexperienced  buyers  performed  as  well  as  the  experienced  buyer. 
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STATISTIX  3.5  31  AUG  91,  9:24 

10:  Phase  11  Processing  Errors  (Buyers  1,  3,  4,  5,  and  7  Removed) 


TUKEY  (HSO)  PAIRWISE  COMPARISONS  OF  MEANS  OF  ERROR  BY  BUYER 
HOMOGENEOUS 

BUYER  MEAN  GROUPS 


2  6.667E-02  I 

6  6.667E-02  I 

8  6.667E-02  I 

THERE  ARE  NO  SIGNIFICANT  PAIRWISE  DIFFERENCES  AMONG  THE  MEANS. 

CRITICAL  Q  VALUE  3.373  REJECTION  LEVEL  0.050 

CRITICAL  VALUE  FOR  COMPARISON  0.0000 
STANDARD  ERROR  FOR  COMPARISON  0.0000 


FIGURE  5-33-  Ti^key’s  Comparison  Op  Low  Error  Boyers 


STATISTIX  3.5  31  AUG  91,  9:38 

ID;  Phase  II/III  Processing  Errors  (Include  Only  Buyer  4  From  Pliase  II) 

XRUSXAL-WALLIS  ONEWAY  NONPARAMETRIC  AOV  FOR  ERROR  =  PHASE 


MEAN 

SAMPLE 

PHASE 

RANK 

SIZE 

2 

63.5 

15 

3 

68.6 

120 

TOTAL 

68.0 

135 

KRUSKAL-WALLIS  STATISTIC  1.1964 

P  VALUE,  USING  CHI -SQUARED  APPROXIMATION  0.2740 

PARAMETRIC  AOV  APPLIED  TO  RANXS 

SOURCE  DF  SS  MS  F  P 


BETWEEN  1  341.7  341.7  1.20  0.2757 

WITHIN  133  3.793E+04  285.2 

TOTAL  134  3.827E+04 

TOTAL  NUMBER  OF  VALUES  WHICH  WERE  TIED  135 
MAX.  DIFF.  ALLOWED  BETWEEN  TIES  1.0E-0005 

CASES  INCLUDED  135  MISSING  CASES  0 


FIGURE  5-34  -  Phase;  II  ArroMAii  n  (Bi  yi.r  4)  /  Phase:  III  Comparison  Oi  Errors  ANOVA 
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A  second  nonparametric  ANOVA  was  performed.  This  time  comparing  the 
performance  of  the  Phase  111  buyers  with  the  errors  recorded  by  buyer  Four  from  the  Phase 
II  manual  testing.  A  low  p-value  will  indicateasignificantdifferencein  the  number  of  errors 
recorded  by  the  Phase  III  buyers.  The  ANOVA  test  computed  a  p-value  of  0.9078  (Figure 
5-35).  This  is  a  very  negligible  indication  that  the  Phase  III  buyers’  performance  was 
statistically  different  to  the  ‘best’  Phase  II  buyer  using  the  manual  method. 

From  this  series  of  testing,  it  is  demonstrated  an  inexperienced  buyer,  using  the 
prototype,  can  perform  at  least  as  well  as  an  experienced  buyer  using  the  current  manual 
system  for  vendor  selection  (when  comparing  error  rates).  There  remains  the  possibility 
that  an  experienced  buyer  can  out  perform  an  inexperienced  buyer  when  they  are  both  using 
the  prototype. 


STATISTIX  3.5  31  AUG  91,  10:00 

10:  Phase  I(  CManual)  (Buyer  A)  /  Phase  111  Processing  Errors 

KRUSKAL-WALLIS  ONEWAY  NONPARAMETRIC  AOV  FOR  ERROR  =  PHASE 


MEAN 

SAMPLE 

PHASE 

RANK 

SIZE 

2 

67.5 

15 

3 

68.  1 

130 

TOTAL 

68.0 

135 

KRUSKAL-UALLIS  STATISTIC  0.0154 

P  value,  using  chi -squared  APPROXIMATION  0.9078 

parametric  AOV  APPLIED  TO  RANKS 


SOURCE 

OF 

SS 

MS 

BETWEEN 

1 

4.219 

4.219 

within 

133 

4.218E*04 

317.2 

TOTAl 

134 

4 .219E*04 

TOTAL  NUMBER  OF  VALUES  WHICH  WERE  TIED  135 
MAX.  DIFf.  ALLOWED  BETWEEN  TIES  1  OE  0005 

CASES  INCLUDED  135  MISSING  CASES  0 


FIGURE  5-35  -  Pham  II  M  \m  \i  (Bi  vih  4)  Pham  III  Ph^x  i.mm,  Ehhi'hs  .•XNOV.A 


PrcKessing  Times.  The  processing  time  recorded  by  each  buyer  in  Phase  II 
testing  were  reviewed.  The  two  buyers  with  lowestcomposite  manual  and  automated  times, 
were  used  in  a  nonparametric  analysis  with  the  eight  buyers  of  Phase  III.  The  Kruskal-Wallis 


One  Way  AOV  nonparametric  ANOVA  test  was  used  to  compare  the  results. 

From  the  combined  Phase  II  testing  the  best  two  processing  times  were  2.214  and 
2.643  minutes  per  purchase  request.  These  times  were  recorded  by  buyers  Five  and  Eight 
resptectively.  An  ANOVA  was  performed  with  only  buyers  Five  and  Eight  from  Phase  II 
automated  and  with  all  buyers  included  from  Phase  III.  As  before,  a  small  p- value  indicates 
a  difference  exists  in  the  mean  processing  times  recorded  by  the  two  groups.  With  a  p- value 
of  0.0002  (Figure  5-36).  there  is  very  strong  statistical  evidence  indicating  there  is  a 
difference  in  the  mean  processing  times  of  the  two  groups. 


STATISTIX  3.5  31  AUG  91,  11:22 

10:  Phase  II  Automated  (Buyers  5  and  8)  /  Phase  III  Processing  Times 

KRUSKAL-WALLIS  ONEWAY  NONPARAMETRIC  AOV  FOR  TIME  =  PHASE 

MEAN  SAMPLE 


PHASE 

RANK  SIZE 

2 

43 

.9  28 

3 

72 

.6  104 

TOTAL 

66 

.5  132 

KRUSKAL- 

WALLIS 

STATISTIC 

13.4903 

P  VALUE, 

USING 

CHI -SQUARED 

APPROXIMATION 

0.0002 

PARAMETRIC  AOV 

APPLIED  TO  RANKS 

SOURCE 

DF 

SS 

MS  F 

P 

BETWEEN 

1 

1.816E-04  ■ 

l.816E-»04  14.92 

0.0002 

WITHIN 

130 

1.582E-^05  ' 

I.217E+03 

TOTAL 

131 

1 .764E+05 

TOTAL  NUMBER  OF  VALUES  WHICH  WERE  TIED  132 
MAX.  DIFF.  ALLOWED  BETWEEN  TIES  1.0E-0005 

CASES  INCLUDED  132  MISSING  CASES  18 


FIGURE  5-.^6  -  Phasi,  II  Ai'TnM..\n  n  (Bi  yi  k  5  &  8)  /  Phasi,  III  PRon.ssiNt;  Timi.s  ANOVA 
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The  question  remains,  which  group,  the  experienced  or  the  inexperienced  buyers, 
had  the  lowest  processing  times.  By  examining  the  means  reported  by  the  descriptive 
statistics  of  the  two  groups  (Figure  5-37),  the  two  fastest  Phase  II  individuals  are  almost 
a  full  minute  per  purchase  request  faster  than  the  Phase  III  buyers. 


STATISTIX  3.5  31  AUG  91,  11:36 

ID:  Phase  II  Automated  (Buyers  5  and  8)  /  Phase  III  Processing  Times 

DESCRIPTIVE  STATISTICS 


PHASE2 

PHASE3 

CASES 

28 

104 

LOWER  95. or.  C.I  . 

1.69A 

2.675 

MEAN 

1 .929 

2.971 

UPPER  95.0'/.  Cl. 

2.163 

3.267 

S.D. 

6.042E-01 

1.523 

S.E.  (MEAN) 

1.142E-01 

1.493E-01 

c.v. 

31.33 

51.26 

MINIMUM 

1.000 

1.000 

MEDIAN 

2.000 

3.000 

MAXIMUM 

3.000 

8.000 

FIGURE  5-37  -  Pha.si:  II  ArroM/vn.n  (BrYi:R.s  5  &  8)  /  Phase  III  PRocE.ssiN(i  Time  DiiscRimvi;  STAnsnrs 


A  second  nonparametric  ANOVA  was  performed.  This  time  comparing  the 
performance  of  the  Phase  III  buyers  with  the  processing  time  recorded  by  the  two  fastest 
Phase  II  buyer’s  manual  time.  A  low  p-value  will  indicate  a  significant  difference  in  the 
processing  time  recorded  by  the  Phase  III  buyers.  The  ANOVA  p-value  of  0.9747  (Figure 
5-38).  is  a  very  weak  indication  that  the  Phase  Ill  buyers’  performance  was  statistically 
different  from  the  ’best’  Phase  II  buyers  using  the  manual  method. 

From  this  series  of  testing,  it  is  demonstrated  an  inexperienced  buyer,  using  the 
prototype  can  perform  at  least  as  well  as  an  experienced  buyer  using  the  current  manual 
system  for  vendor  selection  (when  comparing  processing  time).  However,  the  experienced 
buyer  can  out  perform  an  inexperienced  buyer  when  they  are  both  using  the  prototype. 
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STATISTIX  3.5  31  AUG  91,  11:52 

ID:  Phase  II  Manual  (Buyers  5  and  8)  /  Phase  III  Processing  Times 


KRUSKAL-WALLIS  ONEWAY  NONPARAHETRIC  AOV  FOR  TIME  =  PHASE 

MEAN  SAMPLE 
PHASE  RANK  SIZE 


2  66.3  28 

3  66.6  104 

TOTAL  66.5  132 

KRUSKAL-WALLIS  STATISTIC  0.0010 

P  VALUE,  USING  CHI -SQUARED  APPROXIMATION  0.9747 

PARAMETRIC  AOV  APPLIED  TO  RANKS 

SOURCE  DF  SS  MS  F  P 


BETWEEN  1  1.371  1.371  0.00  0.9748 

WITHIN  130  1.781E-r05  1.370E-r03 

TOTAL  131  1.781E+05 

TOTAL  NUMBER  OF  VALUES  WHICH  WERE  TIED  132 
MAX.  OIFF.  ALLOWED  BETWEEN  TIES  1.0E-0005 

CASES  INCLUDED  132  MISSING  CASES  18 


FIGURE  5-38  —  Pha.si:  II  Mam  ai.  (Bcyi  h.s  5  &  8)  /  Phask  III  Comparison  Oi  Pko(  I-.ssin(i  Timi.s  ANOVA 


Results.  Because  only  two  buyers  in  Phase  II  where  known  to  possess  experience 
in  MilSpec  55182  items,  the  results  from  that  phase  had  to  be  re-examined.  The  two  best 
scores  were  identified  from  each  portion  of  the  Phase  II  testing.  Whether  or  not  these  scores 
represents  the  efforts  of  the  experienced  buyers,  is  inconsequential .  If  the  scores  do  belong 
to  the  experienced  buyers,  the  true  level  of  buyer  performance  which  is  being  used  as  a 
reference,  is  properly  established.  Ifthey  do  not  belong  to  the  experienced  buyers,  the  level 
of  buyer  performance  being  used  as  a  reference,  is  raised  by  the  unknown  difference  in 
performance  between  the  experienced  and  the  inexperienced  buyers.  The  result  is  a  higher 
performance  level  the  Pha.se  III  buyers  have  to  achieve  before  their  performance  can  be 
considered  comparable  to  Phase  II.  the  norm. 
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The  results  obtained  from  this  phase  of  testing  demonstrates  that  the  Phase  III  buyers 
(buyers  without  prior  experience)  can  use  the  prototype  and  perform  the  vendor  selection 
process,  at  least  as  well  as  the  experienced  buyers  using  the  manual  method. 

Conclusions 

Phase  I  testing  sought  an  answer  to  the  question, '  Does  the  system  provide  the  correct 
information?'  The  data  obtained  clearly  indicates  the  prototype  does  provide  the  correct 
information  on  which  to  base  an  award  decision.  Because  not  all  purchase  requests  were 
processed  using  both  the  automated  and  manual  systems,  and  all  of  the  buyers  participating 
in  Phase  11  were  not  familiar  with  the  vendor  selection  process  of  MilSpec  55182  items, 
conclusions  to  the  remaining  phases  cannot  be  as  succinct 

The  objective  of  Phase  11  testing  was  to  address  the  question  Ts  the  buyer  able  to 
select  the  correct  vendor  using  the  prototype  system?’  There  was  a  significant  improvement 
in  the  error  rate  experienced  by  the  buyers  when  using  the  prototype,  as  well  as  improvement 
in  the  processing  time.  A  panel  review  the  complexity  of  the  purchase  requests.  Their 
analysis  indicates  the  improvements  demonstrated  by  the  prototype  could  not  be  explained 
by  the  purchase  requests  being  processed  by  the  automated  system  were  ‘easier’. 

Pha.se  III  testing  wanted  to  provide  an  answer  to  the  question  Ts  the  system  designed 
such  that,  a  person  unfamiliar  with  the  items  being  procured,  is  able  to  make  a  valid  vendor 
.selection  decision?'  Without  all  buyers  in  Phase  II  being  familiar  with  the  items,  the  results 
obtained  are  not  as  strong  as  they  could  have  been.  Regardless,  it  was  demonstrated  that 
using  the  prototype  the  novice  has  the  capability  to  make  an  award  decision,  that  is  at  least 
as  accurate  and  timely  as  the  manual  decisions  made  by  the  ‘best’  of  the  those  individuals 
familiar  with  the  items  being  considered. 
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VI.  Summary.  Findings,  and  Recommendations 


Overview 

The  process  followed  to  reach  the  conclusions  drawn  from  this  paper  is  outlined 
below.  A  summary  of  the  research  methodology,  is  presented.  After  which,  the  research 
findings,  and  recommendations  for  prototype  enhancements  and  follow-on  research  are 
offered. 

Summary  of  Research 

The  current  small  purchase  vendor  selection  process  at  DESC  relies  on  a  manual 
system  to  generate  the  award  decision.  The  current  process  of  small  contract  award 
determination  requires  a  significant  amount  of  labor  to  acquire  the  most  basic  of  data.  In 
addition,  to  assure  a  proper  decision  is  made,  the  buyer  must  maintain  constant  surveillance 
on  dynamic  information,  stemming  from  many  sources.  As  a  result,  the  award  process  is 
subject  to  degradation,  and  doubts  have  arisen  concerning  the  quality  of  those  decisions. 
The  primary  objective  of  this  research  project  was  to  determine  whether  improvements  in 
the  current  small  contracting  process  were  possible. 

To  this  end ,  a  series  of  meetings  was  held  with  DESC  to  investigate  two  preliminary 
questions.  The  first  asked  was,  ‘What  was  the  user’s  perception  of  the  problem?’  The 
second  asked,  ‘How  was  the  current  vendor  selection  process  at  DESC  conducted?’  These 
questions  were  addressed,  and  the  methodology  for  this  research  devised.  This  approach 
comprised  the  design  and  development  of  a  computer  based  decision  support  system.  A 
prototype  running  on  a  personal  computer,  capable  of  analyzing  data  obtained  from  actual 
data  files,  resulted.  The  prototype  coding  was  verified  and  a  formal  validation  plan  was 
developed.  Using  the  testing  procedure  documented  in  Chapter  V.  the  prototype  was 
validated  with  the  help  of  DESC  personnel.  The  results  of  the  testing  were  analvzed.  and 
they  are  summarized  for  the  reader  in  the  Findings  Section  below. 
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Findings 


The  research  questions  presented  in  Chapter  I  are  repeated  below  along  with  each 
conclusion. 

Research  Question  1 .  What  information  must  the  buyer  obtain  before  selecting  the 
proper  vendor? 

Conclusion  1 .  To  answer  this  question  a  series  of  interviews  was  conducted  with 
the  buyers  at  DESC.  The  minimum  information  the  buyer  requires  to  make  an  award 
decision  are; 

a)  the  identity  of  the  item  required  (either  Type  Number  or  NSN) 

b)  the  quantity  of  the  item  required 

c)  the  identity  of  the  vendors  offering  the  item  for  sale 

d)  the  vendor’s  selling  price  for  the  item 

e)  the  identity  of  DeBarred  vendors 

The  following  information  enables  the  buyer  to  make  a  better  informed  decision 
regarding  the  vendor  award: 

a)  quantity  price  reduction  for  the  item  of  interest 

b)  FOB  origin  or  destination 

c)  delivery  time 

d)  performance  problems  with  the  vendors 

e)  performance  problems  with  the  products 

f)  past  purchasing  information  for  the  item 

The  above  items  were  incorporated  into  the  prototype  and  tested  in  the  validation 
process.  The  result  of  testing  suggests  the  prototype  did  incorporate  the  items  necessary 
for  the  buyers  to  make  an  intelligent  vendor  selection. 
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Research  Question  2.  What  information  does  the  buyer  generate  while  awarding 
a  contract  to  the  vendor? 

Conclusion  2.  This  question  was  answered  by  interviews  with  the  buyers.  The 
DESC  Form  800  is  generated  by  the  buyers  after  making  the  award  der’<^-L.i.  1  ne  significant 
elements  of  this  form  were  identified.  Information  required  to  complete  the  form  was 
as.sembled  on  the  award  screen  in  the  prototype.  Buyer  interviews  confirmed  the 
information  presented  on  the  award  screen  was  sufficient  to  process  the  required  DESC 
Form  800. 

Research  Question  3.  What  automated  management  systems  are  available,  and.  of 
these  systems,  which  ones  could  .satisfy  the  needs  of  DESC.  given  the  type  of  data  available 
and  the  results  required? 

Conclusion  3.  A  literary  review  was  conducted.  The  review  focused  on  the  various 
automated  management  systems  commonly  used  today.  Three  types  were  reviewed;  a  data 
base  management  system,  a  decision  support  system,  and  an  expert  system.  Of  these 
management  systems,  the  decision  support  system  appeared  to  be  the  closest  match  for 
DESC's  problem. 

DESC  sought  a  system  that  would  assi.st  their  buyers  in  performing  the  vendor 
selection  process.  They  were  looking  for  a  system  that  would  organize  information  relevant 
to  specific  requests,  thereby  enabling  the  making  of  timely,  informed  decisions.  A  decision 
support  system  supports  this  open-ended  decision  analysis.  The  user  provides  the 
constraints  of  the  problem  and  the  decision  support  system  generates  possible  alternative 
solutions.  The  user  then  employs  personal  insights  to  select  the  best  solution  from  the 
alternatives  presented. 

The  validation  results,  and  feedback  from  the  user  questionnaire,  contlrmed 
developing  the  prototype  m  the  vein  of  a  decision  support  system  was  sound.  By  using  the 
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prototype,  the  buyers  tested  were  able  to  achieve  a  significant  reduction  in  errors.  The 
percentage  of  errors  decreased  from  21.7%  using  the  current  process,  to  5.8%  using  the 
prototype.  Processing  time  was  almost  cut  in  half.  The  prototype  reduced  the  time  required 
for  each  request  by  two  minutes. 

In  the  questionnaires  completed  by  the  buyers,  not  one  indicated  the  approach  used 
by  the  prototype  was  incorrect.  Acceptance  of  the  system  was  unilateral.  They  are  willing 
to  adopt  this  system  into  their  working  environment,  and  are  eager  to  do  so. 

Because  of  the  above  results,  structuring  the  prototype  design  based  on  a  decision 
support  system,  proved  to  be  both  theoretically  and  functionally  correct. 

Research  Question  4.  Can  an  effective  automated  system  be  designed,  developed 
and  employed  to  assist  the  buyer  decision  process  at  DESC? 

Conclusion  4.  Yes,  without  reservation.  As  stated  in  conclusion  three,  when  the 
buyers  used  the  prototype,  there  was  a  significant  reduction  in  errors  produced  in  processing 
the  purchase  request.  Not  only  were  there  fewer  errors,  but  it  took  less  time  to  process  the 
requests  as  weli. 

The  system  can  also  be  successfully  used  by  personnel  who  are  unfamiliar  with  the 
products.  The  test  results  confirm  that  an  inexperienced  buyer  can  perform  the  vendor 
selection  process  at  least  as  well  as  the  best  buyers  using  the  manual  system  today.  The 
implications  of  this  finding  bear  directly  on  the  department  managers.  Flexibility  in 
personnel  utilization  can  be  enhanced.  No  longer  will  the  work  have  to  wait  on  'Mary'  or 
‘Joe’  to  return  from  vacation.  The  workload  can  be  effectivly  shared  by  all  buyers. 

There  is  overwhelming  evidence  indicating  this  prototype  system  is  a  valuable  tool 
in  the  vendor  selection  process.  With  DESC's  desire  to  bring  cohesiveness  to  the  award 
process,  and  the  ever  shrinking  pool  of  resources  in  which  to  operate,  it  is  clear  the  current 
methods  of  doing  business  must  be  re-examined.  Developing  and  implementing  the 
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prototype  is  a  proven  solution  that  will  enhance  the  productivity  of  the  smalt  purchase, 
vendor  selection  process.  A  process  which  consumes  87%  of  the  contracting  workload  at 
l'ESC. 

Summary  Of  Findings 

The  goal  of  this  research  was  to  demonstrate  improvements  in  the  current  small 
contract  vendor  selection  process  were  possible.  Through  personal  interviews,  knowledge 
of  the  current  process  was  obtained.  Further  investigations  identified  deficiencies  in  the 
methods  used  for  vendor  selection.  A  system  was  designed  striving  to  reduce  the  number 
of  obstacles  to  the  process. 

Simplicity  for  the  user  was  the  primary  concern  in  system  design.  A  balance  was 
sought  between  too  little  and  too  much  informat'on  on  the  user  screens.  Maximizing  the 
utility  of  the  system  with  a  minimum  of  user  inputs  was  the  design  goal. 

The  prototype  that  evolved  from  this  effort  was  tested  at  DESC,  by  the  very  buyers 
who  the  system  was  designed  to  assist. 

The  results  of  the  prototype  testing  showed  it  is  possible  to  achieve  a  significant 
reduction  in  purchase  request  processing  time  while  increasing  the  accuracy  of  the  award 
decisions.  Usability  of  the  system  by  those  unfamiliar  with  the  items  being  procured  was 
demonstrated  in  the  third  phase  of  testing.  The  timeliness  and  quality  of  the  decisions  made 
by  this  group  were  equivalent  to  those  made  by  experienced  buyers  using  the  manual 
process. 

From  the  analysis  of  the  test  data,  and  the  responses  provided  by  the  users,  the 
researcher  is  confident  the  system  developed  improves  the  vendor  selection  process. 

Recommendations  for  Future  Research 

Before  the  seed  .sown  by  this  research  will  bear  fruit,  it  must  be  nurtured  by  other 
research.  VASPP  is  still  primarily  a  concept.  This  research  has  established  a  point  of 


departure  for  further  development  of  the  VASPP  system,  however,  there  is  still  much 
undone.  Before  VASPP  can  be  realized,  an  interface  for  the  vendor  to  enter  VASPP,  must 
be  designed.  Along  with  this,  the  logic  required  to  govern  vendor  data  input  verification 
must  be  examined. 

The  prototype,  with  its  dependence  on  data  from  many  sources,  is  very  reliant  on 
the  integrity  of  its  support  files.  Structure  and  control  of  the  vendor  pricing  data  file  must 
be  developed  to  assure  its  integrity.  Data  maintenance  and  transfer  from  all  supporting  data 
files  needs  to  be  addressed.  Without  accurate  information  available  to  the  system,  inferior 
performance  can  be  expected. 

The  vendor  selection  process  can  be  enhanced  beyond  that  demonstrated  by  the 
prototype.  Both  the  upstream  and  downstream  activities  are  automated.  Purchase  request 
transmittal  to  and  from  the  buyer  should  be  examined  to  take  advantage  of  a  computer  to 
computer  information  transfer.  Achievement  of  this  interface  will  reduce  the  generation 
of  paper  products  and  personnel  overhead,  while  increasing,  throughput  and  improving  the 
accuracy  of  the  products  produced. 

Recommendation  for  Future  Modification 

The  prototype  was  developed  using  a  decision  support  s  stem  as  a  model.  The 
development  of  an  expert  system  went  beyond  the  time  limits  constraining  this  paper. 
However,  now  having  established  a  solid  foundation  that  identifies  the  requirements  of  the 
buyers,  it  seems  possible  an  expert  system  can  bedeveloped.  The  question.  ‘Can  the  vendor 
selection  process  be  defined  with  sufficient  depth  to  develop  an  expert  system?',  needs  to 
be  re-addressed.  If  this  is  possible,  an  expert  system  overlay  for  the  prototype  could 
completely  automate  the  vendor  selection  process. 

An  automated  system  already  produces  purchase  request  information,  and  the 
buyers  submit  their  award  decisions  to  another  automated  system.  With  an  expert  system 
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performing  the  award  decision,  a  seamless  transition  could  take  place  between  the 
requirement  identification  and  contract  award.  This  could  result  in  a  completely  automated 
small  vendor  award  process,  increasing  decision  integrity  and  decreasing  lead  time. 

Lessons  Learned 

A  significant  portion  of  the  success  of  this  project  rests  with  the  cooperation  afforded 
to  the  researcher  by  DESC.  Prior  knowledge  with  the  acquisition  process  was  minimal. 
The  personnel  eagerly  answered  questions  and  patiently  reiterated  the  vendor  selection 
process  as  necessary.  The  significant  lesson  learned  from  these  efforts  is  the  importance 
of  maintaining  an  open  line  of  communication  between  the  user  and  the  developer.  In  this 
research  it  was  doubly  important.  Not  only  did  the  expectations  of  management  have  to 
be  satisfied,  but  also  the  needs  of  the  system  user  had  to  be  carefully  cultivated.  Without 
constant  communication  with  the  customer,  a  successful  system  could  not  have  been 
developed. 

Final  Notes 

The  use  of  an  automated  system  has  been  shown  to  increase  the  effectiveness  of  the 
vendor  selection  process.  This  is  but  one  of  countless  areas  where  productivity  could  be 
improved  with  the  Judicious  use  of  automated  techniques.  With  government  being  forced 
to  accept  an  ever  increasing  work  load,  while,  simultaneously,  resources  are  being  denied, 
productivity  must  be  improved  wherever  possible.  Managers  should  not  overlook  the 
benefits  of  properly  applied  computer  support. 
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Appendix  A:  Program  Code 


7/3Q/91  AVSA.PRG 

'':4Q  Cooyright.  United  States  Air  Force,  '991 

Automated  Vendor  Selection  Assistant 

*-*t******tii*tt*tt*tt**i**tt**t*tt***tt*tt*******t*tttt*****t*xtit**tt* 


Program:  AVSA.PRG 

System:  Automated  Vendor  Selection  Assistant 
Autncr:  Caot  Daniel  E.  Hagmaier 
Cooyright  (c)  1991,  United  States  Air  Force 

Calls:  TlTLESCR-'orocedure 
:  INFO_SCR--orocedure 
:  iNlTUSCR-'orocedure 
:  iNPUTSCR-'oroceaure 
:  SELCTSCR-'orocedure 
:  SELCTVEN.PRG 
:  ANALZSCR-'Oroceoure 
:  PREPVEN.PRG 
:  ^R ' CESCR-'orocedure 
:  VENDRSCR-'orocedure 
:  COCFSCR-'orocedure 
:  PROSMSCR-'Orocedure 
:  AWARDSCR-'Orocedure 
:  MOVENSCR-'orocedure 

,ses:  PR_’’£MP.DS- 
:  ^0LD.D9- 


Zocunerted: 


SMAPI  vers'or  '.‘'3 


n:”al.:ze 


*  Establ’shes  the  conf 'gurat'or  the  system.  t  def'^es  the  * 

*  way  the  disolay  screen  aocears  to  the  ^ser.  :t  a’so  * 

*  def'hes  some  of  the  ooerating  carameters  for  the  orogram.  * 

*  X 

xxxxxixxxxixxxxxxxxxxxxxxxxxxxxxxtxxxxxxixxxxxxtixxxxxxxxxxxxxxxx 


S£"  BEL-  0F= 

3E"  CENTURY  0F= 

SE’  COLOR  '0  G/3.R3/N.3G 
SET  decimals  "0  4 
3E'  de-E'e:  on 
SE"'  ESCAPE  Cc- 
3E'  PROCEDURE  ''0  screens 
SE*  SCOREBOARD  OF^ 

SET  S’’A'’uS  OFF 


Si  Sucoresses  t!^e  'Beeo' 

&&  Allows  irD;jt  o'  2  d'g't  year 
Sets  t^e  d'sclay  cc’ors 
44  Numoers  d'so’ayed  w/  4  dec'ma' 
44  .gnores  deleted  records 
44  :nh-b:ts  the  lESO''  kev 
44  Coens  the  c'oceoure  '-‘e 
44  :''h:b-ts  t^'e  '-ne  D  oromots 
44  .nhib'ts  the  stat^iS  ''ne 


A-' 


7/30/91  AVSA.PRG  Page 

11:40  Copyright,  United  States  Air  Force,  1991 

Automated  Vendor  Selection  Assistant 

SET  TALK  OFF  &&  Inhibits  commano  responses 


Program  Control  ********♦**♦♦♦****♦♦<»♦♦*»♦♦♦♦«♦♦*♦**»* 

*  * 

*  Controls  the  execution  of  all  programming  routines,  up  to  * 

*  user  termination.  ♦ 

*  ♦ 


STORE  ”  "  TO  mchoice 
STORE  .T.  TO  mnew_nsn 
DO  TitleScr 
STORE  .F.  TO  mend 
00  WHILE  .NOT.  mend 
DO  lnfo_Scr 
IF  mchoice  :  "Y” 


ii  User  selection 
4&  Program  control  flag 
44  Display  opening  screen 
44  Program  termination  fls 


44  Run  program 


I  "^END  :: 


44  Display  information  screen 
44  User's  resoonse 


DECLARE  SYSTEM  VARIABLES 


Do  InitlScr 
IF  mnew  nsn 


44  User  information  screen 
44  This  will  be  a  new  NSN 


)>>  INITIALIZE  MEMORY  VARIABLES 

STORE  SPACE(16)  TO  mnsn 
STORE  '  ’  TO  mreturn 

STORE  '  '  TO  msetaside 

STORE  '  '  TO  mhist_cage 

STORE  '  '  TO  mhist_date 

STORE  0  TO  mhist_pr 
STORE  3  TO  mquantity 
STORE  0  TO  mlow_price 
STORE  0  TO  mrdd~ 

STORE  0  TO  mday 
STORE  .F.  TO  mlow 
STORE  .F .  TO  munit_pr 
STORE  .F.  TO  mvariation 
STORE  .F.  TO  mhi story  1 


44  NSN  of  item 

44  Last  displayed  user  screen 
44  Set-aside  procurement 
44  Most  recent  contracted  vendor 
44  Most  recent  purchase  date 
44  Most  recent  purchase  price 
44  Amount  of  item  desired 
44  Lowest  cost  to  procure  item 
44  Required  delivery  date 
44  The  number  of  today's  date 
44  Price  may  be  to  low  flag 
44  Display  unit  price  flag 
44  Variation  exceeds  limit  flag 
44  Price  greater  than  recent  histo 


STORE  .F.  TO  mhistoryZ 


44  No  prior  NSN  history  flag 
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97 

98 

99 
100 
101 
102 
103 
^04 

105 

106 
’07 
108 

109 

110 
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>>>  !N!’’!ALIZE  O'SPLAY  MATRIX  VARIABLES  <<< 

STORE  1  TO  mcounter  H  mcagel  through  mcage9 

DO  WHILE  mcounter  <  10 

STORE  'MCAGE'+LTRIM(STR(mcounter))  TO  mcage 
STORE  ’  '  TO  Simcage 

STORE  mcounter  *  1  TO  mcounter 
ENOOO 

STORE  1  TO  mcounter  &&  morderl  through  norder6 

DO  while  mcounter  <  7 

STORE  'MOROER’+LTRIM(STR(mcounter))  TO  morder 
STORE  0  TO  Smorder 
STORE  mcounter  +  1  TO  mcounter 
ENDOO 


112 

113 

114 

115 
’16 

117 

118 

119 

120 
121 
122 

123 

124 

125  * 

126 

127 

128 

129 

130  * 
’31 

132 

133 
’34 
135 
•36 

.37  « 

’38 
'  39 
UC 
’4’ 

142 

143 


STORE  1  TO  mrow  ii  me)(t_1_1  through  mext_9_5 

DO  WHILE  mrow  <  10 
STORE  1  TO  mcolumn 
DO  WHILE  mcolumn  <  7 

STORE  'MEXT_’+LTRIM(STR(mrow))+'_'*LTRm(STR(mcolumn))  "0  mep 
STORE  0  TO  4mep 
STORE  mcolumn  +  1  TO  mcolumn 
ENOOO 

STORE  mrow  +  1  TO  mrow 
ENOOO 
END  IF 


>))  SET  JULIAN  DATE  <(< 

IF  DAY(0ATE())  O  mday  44  mday  contain  the  current  day’ 


■'))  GET  THE  SYSTEM  DATE  <(< 

STORE  YEAfl(DATE())  TO  myear 
STORE  MONTH(OATE())  TO  mmonth 
STORE  OAY{OATE())  TO  mday 


calculate  ’’HE  days  IN  THE  °AST  MONTHS 


DO  CASE 

CASE  mmonth  :  1 

STORE  0  TO  mj_date 
CASE  mmonth  -  2 

STORE  31  TO  mj_date 


A-3 


11:40 

Copyright,  United  States  Air  Force,  1991 

Automated  Vendor  Selection  Assistant 

144 

CASE  mmonth  =  3 

145 

STORE  59  TO  mj_date 

146 

CASE  mmonth  =  4 

147 

STORE  90  TO  mj_date 

148 

CASE  mmonth  =  5 

149 

STORE  120  TO  mjjate 

150 

CASE  mmonth  =  6 

151 

STORE  151  TO  mj_date 

152 

CASE  mmonth  =  7 

153 

STORE  181  TO  mj_date 

154 

CASE  mmonth  =  8 

155 

STORE  212  TO  mjjate 

156 

CASE  mmonth  =  9 

157 

STORE  243  TO  mj_date 

158 

CASE  mmonth  =  10 

159 

STORE  273  TO  mjjate 

160 

CASE  mmonth  =  1 1 

161 

S, JRE  304  TO  mj_date 

162 

CASE  mmonth  :  12 

163 

STORE  334  TO  mj_date 

164 

ENOCASE 

165 

166 

167 

« 

)>>  ADD  THE  DAYS  OF  THE  CURRENT  MONTH  <(< 

168 

169 

STORE  mj_date  +  mday  TO  mj_date 

170 

171 

172 

* 

>>>  CORRECT  FOR  LEAP  YEAR  <<< 

173 

174 

STORE  MF(l10D(myear,4)  :  0,.T.,.F.)  TO  mleap_yr 

175 

IF  mleap_yr  .AND.  mj_date  )  59 

176 

STORE  mj_date  +  1  TO  mj_date 

1  7  " 

ENDl^ 

'IB 

END  IF 

179 

190 

181 

« 

>))  INPUT  AND  ANALYZE  USER  REQUEST  <<< 

182 

183 

SET  CONFIRM  ON  iS  Must  use 

183 

t 

184 

DO  InputScr  S4  Get  users 

185 

IF  mchoice  :  'Q'  &4  Has  the  input  been  aborted 

186 

LOOP  44  Return  to  beginning  of  Do  While 

187 

END!'^ 

188 

DO  SelctScr  44  Display  ii 

189 

DO  SelctVen  44  Get  biddi 

190 

Page  4 
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191 

IF  RECCOUNTO  >  0 

If  bidding  vendors  exist 

192 

DO  AnalzScr 

&&  Display  information  screen 

193 

DO  PrepVen 

&&  Prepare  vendors  for  display 

194 

195 

196  * 

))>  DISPLAY  USER  SCREENS  <<< 

197 

198 

STORE  '  '  TO  mchoice 

&&  Reset  user’s  choice 

199 

DO  WHILE  UPPER(mchoice)  <>  ’Q’ 

200 

DO  CASE 

201 

CASE  UPPER(mchoice)  =  'U' 

202 

STORE  .T.  TO  munit_pr 

203 

DO  PriceScr 

204 

CASE  UPPER(mchoice)  =  'E' 

205 

STORE  .F.  TO  munit_pr 

206 

DO  PriceScr 

207 

CASE  UPPER(mchoice)  :  'V' 

208 

DO  VendrScr 

209 

CASE  UPPER(mchoice)  =  'C' 

210 

DO  CdcfScr 

2’1 

CASE  UPPER(mchoice)  =  'P' 

212 

DO  ProbmScr 

213 

CASE  UPPER(mchoice)  :  ’A' 

214 

DO  AwardScr 

215 

OTHERWISE 

216 

STORE  .T.  TO  munit_pr 

217 

DO  PriceScr 

218 

ENDCASE 

219 

ENDDO 

220 

221 

STORE  .T.  TO  mnew_nsn 

222 

223 

ELSE 

44  1 f  no  vendors  qua! ify 

224 

DO  NoVenScr 

225 

END  IF 

226 

ELSE 

44  If  user  is  finished 

227 

STORE  .T.  TO  mend 

44  Set  MEND  = 

228 

END  IF 

229 

230 

231  * 

)>>  PREPARE  DATA  ‘'ILES  f'OR  NEXT  USE  <<< 

232 

233 

CLOSE  DATABASES 

234 

SET  SAFETY  OFF 

44  Allow  unprompted  delet'on 

235 

USE  Dr_temD 

236 

ZAP 

44  Remove  records  from  pr_temc,dbf 

237 

USE  hold 

238 

ZAP 

44  Remove  records  from  hold.dbf 
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239  SET  SAFETY  ON 

240 

241  ENDOO 

242 

243 

244  ♦**  CLEAN-UP  ***U***i*itU*******************t*****U****U* 


245  ♦  * 

246  *  This  section  closes  open  files,  releases  the  memory  ♦ 

247  *  variables,  and  restores  dBase  to  its  default  operating  * 

248  *  environment.  * 

249  *  * 


25Q  *t***i%ttt:ift***********1tt*U**tt****************t****t*****i**** 

251 


252 

CLEAR  ALL 

&&  Closes  all  files  &  memory 

253 

SET  8ELL  ON 

&&  Enables  the  'Beep' 

254 

SET  CONFIRM  OFF 

3i&  Enables  Auto  Advance 

255 

SET  DECIMALS  TO  2 

&&  Numbers  displayed  w/  2  decimals 

256 

SET  DELETED  OFF 

&&  Activates  deleted  records 

257 

SET  ESCAPE  ON 

S&  Enables  the  <ESC>  key 

258 

SET  SCOREBOARD  ON 

Enable  1 ine  0  display 

259 

SET  STATUS  ON 

&&  Enables  the  status  bar 

260 

SET  TALK  ON 

is  Enables  command  responses 

261 

262  *;  EOF:  AVSA.PRG 
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.$itU*******Ut**U**U***U************************iHHt*U****t**Ut* 

Program:  PREPVEN.PRG 

System:  Automated  Vendor  Selection  Assistant 
Author:  Capt  Daniel  E.  Hagmaier 
Copyright  (c)  1991,  United  States  Air  Force 

:  Called  by:  AVSA.PRG 


CDCF.DBF 
QUALITY.  DBF. 
VENDOR. DBF 
HOLD. DBF 
MODEL. DBF 
HI  STORY. DBF 


Indexes 


CDCF_N_C . NDX 

q.CAGE.NDX 

V_C_M1L.NDX 

H_EXT_PR.NDX 

H_0RD_Q.NDX 

HIST  N  D.NDX 


Documented:  7/30/91  ’1:37  SNAP!  version  1.73 

ti*t****$*t*t**********************tti*tt*t***»*t****ttt***t*i*ttttt* 


CHECK  VENDOR  PERFORMANCE 


*ttt****t*$******t****xt*tiiHt*** 


This  section  of  the  program  check  each  vendor  remaining  in  * 
the  data  file  PR_TEMP.  They  are  checked  for  past  perform-  * 
ance  problems  as  well  as  outstanding  performance.  Flags  are  * 
set  for  each  vendor  indicating  the  results  of  this  search.  * 

* 

t$t****t**t***t*****$*ttt**t*tit***ttti*t*ttttt*itttt*tt***ttttt 


CHECK  FOR  PROBLEM  VENDOR  INFORMATION 


SELECT  Dr_temD 
GO  TOP 

DO  WHILE  .NOT.  EOF() 
SELECT  dcr’ 

SEEK  Dr_temo->cage 
FOUND! ) 

IF  restricti  <> 


.OR.  restrictC 


&&  Activate  PRJEMP.DBF 
&&  Set  pointer  to  first  record 
&&  Scan  entire  file 
&&  Activate  DCRL.DBF 
iS  See  if  cage  exists  m  DCRL.DBF 
4&  If  cage  is  in  the  DCRL.DBF 
.OR.  restrict 3  <>  ’  ' ; 


■OR.  restrictA  <>  '  ’  .OR.  restricts  <>  ’  ' 
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51 

52 

53 

54 

55 

56 

57 

58 

59 

60 
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62 

63 

64 

65 


7/30/91  PREPVEN.PRG  Page  2 

11:40  Copyright,  United  States  Air  Force,  1991 

Automated  Vendor  Selection  Assistant 
REPLACE  pr_temp->prob  WITH  .T. 

ENDIF 
END  IF 

SELECT  pr_temp  &&  Activate  PR_TEMP.DBF 

SKIP  &&  Move  pointer  to  next  record 

ENDDO  &&  Repeat  until  End-Of-File 


*  )>>  CHECK  CDCF  FILE  <<< 

SELECT  C 

USE  cdcf  INDEX  cdcf_n_c 

SELECT  pr_temp 
GO  TOP 

DO  WHILE  .NOT.  £OF() 

SELECT  cdcf 


Establish  2nd  work  area 
&&  Open  COCS  file 


66 

SEEK  mnsn+pr_terao->cage 

&& 

Look  to  see  'f  exists 

67 

.POUND! ) 

68 

REPLACE  pr_temp-)cdcf  WITH  .T. 

69 

ENDIF 

70 

SELECT  pr_temo 

&& 

Activate  PR_TEMP.dbf 

71 

SKIP 

&& 

Advance  pointer  to  check  next  r 

71 

ecord 

72 

ENDDO 

73 

74 

75 

*  >)>  CHECK  QUAL:Tv  VENDOR  ^ILE  (<< 

76 

77 

SELECT  C 

S.& 

Establish  alternate  work  area 

78 

USE  qual ity  INDEX  q_cage 

&& 

Open  qual ity  file 

79 

30 

SELECT  pr_temo 

&& 

Activate  PR_TEMP.DBF 

81 

GO  TOP 

&& 

Set  pointer  to  first  record 

82 

DO  WHILE  .NOT.  EOF() 

&& 

Scan  the  entire  file 

83 

SELECT  quality 

&& 

Activate  QUAL ITY. DBF 

34 

SEEK  ?r_temp-)cage 

&& 

See  if  cage  exists  in  QUALITY, D 

84 

BP 

85 

IF  FOUND!) 

&& 

I f  cage  is  m  QUAL : "v .DBF 

86 

REPLACE  cr_temo->qua1  ity  WmH  .T. 

&& 

Set  the  quality  flag  for  the  ve 

36 

ndor 

87 

ENDIF 

88 

SELECT  pr_temp 

&& 

Act'vate  PRJEMP.DBF 

89 

SKIP 

&& 

Move  pointer  to  next  record 

90 

ENDDO 

&& 

Repeat  unt-i  1  End-Of-Fi  le 

9' 

92 

93 
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***  ORGANIZE  INFORMATION  ****$******$****t****t*****t*tt***t* 
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*  This  section  of  the  program  organizes  the  selected  vendors  * 

*  on  minimum  quantity  offered  which  satisfies  the  requirement.* 

*  A  matrix  of  memory  variables  are  filled,  which  will  latter  * 

*  be  displayed  by  the  user  screens.  * 

*  * 
*$*ii;ttt********:*i*:******************************tttit*t*********if* 

*  >)>  ESTABLISH  DATA  FILES  <<< 


SELECT  B 

USE  vendor  INDEX  v_c_mi1 
SELECT  C 
USE  hold 


&4  Select  an  alternate  work  area 
&&  Activate  VENDOR. dbf 
&&  Select  an  alternate  work  area 
&&  Open  a  temporary  storage  db  fil 


SELECT  pr_temp 

SET  RELATION  TO  cage+mi l_spec  INTO  vendor 
GO  TOP 


&&  Activate  primary  work  area 
&&  Link  datafiles  together 
&&  Set  pointer  to  the  first  record 


t  * 

*  The  following  code  finds  the  first  column  in  the  temporary  ♦ 

*  vendor  file  who's  quantity  is  equal  to,  or  exceeds  the  * 

*  requirement.  * 

*  * 
******t***tt******t****t*tt******t***t****t****-*****************t 

*  >>>  SCAN  VENDOR  PRICES  <<< 


DO  WHILE  .NOT.  EOF()  &&  Examine  all  vendors 

STORE  1  TO  mseries  &&  Field  oointer  ^  1 

STORE  'QMAX'>LTR!M(STR(mseries))  i^O  mmax  8i&  Create  pointer  to  QMAX1 

IF  Smmax  <  mquantity  .AND.  &mmax  <)  0  &4  Test  QMAXl 

STORE  .T.  TO  mnextcol  44  Set  program  control  flag 

ELSE 

STORE  .F.  TO  mnextcol 
END  If 

DO  WHILE  mnextcol  .AND.  .mseries  <  11  44  Examine  uo  to  QMAX10 

STORE  mseries-t-1  TO  mseries  44  Add  one  to  series 

STORE  'QMAX'+LTR:M(STR(mseries))  TO  mmax 

T  4nTnax  >:=  mquantity  .AND.  4mmax  *  mquant’ty  >::  vendor-i>min_order 
STORE  .F.  TO  mnextcol 
END  IF 

IF  4mmax  :  0  44  No  further  oricing  information 


44  Examine  uo  to  QMAX10 
44  Add  one  to  series 
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141 

142 

143 

144 

144 

145 

146 

147 

148 

149 

150 

151 

152 

153 

154 

155 

156 

157 

158 

159 

160 
161 
'62 

163 

164 

165 

166 

167 

168 
•69 
170 

«  •?  1 

'  I  I 

172 

•73 

174 

’75 

176 

'.r. 

178 

’79 

180 

181 

182 

183 

•34 

185 

•86 

187 
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STORE  .F.  TO  mnextcol  &&  Set  program  control  flag 

STORE  mseries  -  1  TO  mseries  Si&  Correct  mseries 

ENDIF 

ENDOO  iS  Repeat  until  all  prices  examine 

d 


*  * 

*  Having  found  the  minimum  amount  the  vendor  will  sell  that  * 

*  meets  the  requirements,  that  and  all  subsequent  price  * 

*  breaks  are  transferred  to  a  temporary  data  base  named  HOLD.* 

*  * 
*tt*tt**t****t*t*****i****t*******t*****t********t**********t*** 

*  >>>  MOVE  PRICING  INFORMATION  TO  HOLD. DBF  <<< 

STORE  •A-)QMAX'+LTR!M(STR(msenes))  TO  mmax 
DC  WHILE  mseries  <  11 
IF  immax  =  0 
EXIT 
ENDIF 

SELECT  hold 
APPEND  BLANK 

REPLACE  cage  WITH  a-)cage 
STORE  ’A->QMIN'+LTRiM{STR(mseries))  TO  mmin 
STORE  'A->PRICE''^LTR!M{STR(mseries))  TO  mprice 
REPLACE  unit_price  WITH  impnce 

*  >>)  CALCULATE  THE  ORDER  QUANTITY  AND  EXTENDED  °RICE  <(< 

IF  mquantity  <  imm’n 

REPLACE  ext_price  WITH  4mmin  *  Smcrice 
REPLACE  ord_quant  WITH  &mmin 

ELSE 

IF  Smmax  <  mquant’ty 

STORE  ( INT(mquantity/&mmax)4’1)*&mmax  TO  mquant 
REPLACE  ext_price  WITH  mquant  *  Simprice 
REPLACE  ord_quant  WITH  mquant 

E.SE 

REPLACE  ext_Drice  WITH  mquantity  *  Jimpnce 
REPLACE  ord_quant  WITH  mquantity 
ENDIF 

ENDIF 


CHECK  AND  ADoL'SY  LOT  SIZE 


7/30/91 

11:40 


Page 


188 

189 

190 

191 

192 

193 
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207 
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209 

210 
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220 
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227 

228 
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IF  vendor-)  iot_sue  >1  &&  Is  an  adjustment  reauiredl’ 

IF  IMT(ord_quant/vendor-)Iot_size)  <)  ord_quant/vendor->lot_size 
STORE  1  TO  munits 

DO  WHILE  vendor-) lot_size*munits  <  ord_quant 
STORE  munits  +  1  TO  munits 
ENDDO 

REPLACE  ord_quant  WITH  vendor-)lot_size*munits 
REPLACE  ext_pnce  WITH  vendor->Iot_size*munits*un  ;t_pnce 
ENDIF 
END  IF 

>>)  CHECK  FOR  MINIMUM  VENDOR  ORDER  QUANT 'TY  <(< 

:F  ext_price  <  vendor->min_order 

STORE  vendor-)min_order/unit_pr ice  TO  munits 
:NT(mumts)  <)  munits 
STORE  INT(munits  +  1)  TO  munits 
ENDIF 

REPLACE  ord_quant  WITH  munits 
REPLACE  ext_price  WITH  munits  ♦  unit_pr'!ce 
ENOl'" 

STORE  mseries  +  1  TO  mseries 
STORE  'A-)QMAX'+LTRlM(STR(mseries))  TO  mmax 
ENDDO 

SELECT  pr_temp 
SKI? 

ENDDO 


* 

*  Now,  :n  the  HOLD  data  file,  is  a  list  of  all  qualified 

*  vendors  who  have  bid  on  the  -tern.  Along  with  the  cage 

*  code,  the  associated  quantity  and  extended  pr-ce  are 

*  stored.  The  next  instructions  ident-fies  the  lowest  our- 

*  erase  once  and  sets  specific  data  flags  concernino  the 

*  lowest  c'^ice. 

* 

*  >>>  iSFCRV  THE  USER  OF  ^HE  "RCGRA?^  S^A'^US  < ' 

CLEAR 

@  5.:?  'C  '0.49  CCU3LE 
3  3,3G  3A'^  '0'"gan*::ng  Vendors' 


t 

t 

I 

X 

X 

X 

X 

X 
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236 

237 

238 

*  >>>  FIND  THE  LOWEST  COST  <<< 

239 

240 

SELECT  0 

&&  Select  an  alternate  work  area 

241 

USE  model 

&&  Open  the  management  MODEL. DBF 

242 

SELECT  hold 

&&  Activate  the  HOLD. DBF 

243 

SET  INDEX  TC  h_ext_pr,  h_ord_q 

&&  Activate  the  indexes  for  HOLO.J 

243 

3F 

244 

RE  INDEX 

&&  Update  the  indexes 

245 

GO  TOP 

&&  Move  pointer  to  the  first  recor 

245 

d 

246 

247 

248 

♦  >>>  COMPARE  LOW  PRICE  TO  NEXT  LOWEST 

U( 

249 

250 

STORE  ext_price  “^0  mlow_price 

Si  Record  R1  ext_pnce  is  lowest  o 

250 

rice 

251 

STORE  unit_price  TO  mnet_price 

Si  Transfer  unit  price  to  memory 

252 

STORE  cage  lO  mcage 

Si  Transfer  cage  to  memory 

253 

LOCATE  FOR  cage  <>  mcage 

SS  Look  for  the  next  lowest  vendor 

254 

IF  FOUNDO 

SS  If  another  vendor  ex’sts 

255 

IF  mnet_pnce  *  ( (model-) low/100)  +  1 )  < 

unit_price 

256 

STORE  .T.  TO  mlow 

SS  If  price  too  low,  set  flag 

257 

ENDIF 

258 

END  1 F 

SS  End  of  comparison 

259 

260 

261 

*  >>>  CHECK  FCR  VARIATION  COSTS  <(< 

262 

263 

SELEC^  pr_temp 

SS  Activate  PRJEMP.DBF 

264 

LOCATE  FOR  cage  =  mcage 

SS  Locate  vendor  with  lowest  price 

265 

IF  mlow_price  *  ((vendor-)qty_var_m/100)+1' 

)  >  model->up_l imit 

266 

STORE  .T,  TO  mvariation 

SS  Set  flag 

267 

ENDIF 

SS  End  of  variation  check 

263 

269 

270 

27’ 

272 

*  >>)  CHECK  HISTORY  <<< 

SELECT  C 

SS  Select  alternate  work  area 

273 

USE  HISTORY  INDEX  hist_n_d 

SS  Activate  HISTORY. DBF 

274 

SEEK  mnsn 

SS  Look  for  NSN 

275 

IF  FOUND (  ; 

SS  If  it  IS  on  file 

276 

277 

.78 

2 '9 

*  >)'  MND  ^'OST  RECENT  PURCHASE  <<< 

DO  WH ! lE  "sn  ;  mnsn 

SS  Go  one  record  beyond  matching  N 

279 

SN 
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280 

SKIP 

Advance  record  pointer 

281 

ENOOO 

282 

SKIP  -1 

ii  Backup  one  record 

283 

284 

STORE  date  TO  mhist_date 

Transfer  to  memory  variables 

285 

STORE  price  TO  mhist_pr 

286 

STORE  cage  TO  mnist_cage 

287 

288 

*  >>>  COMPARE  UNIT  PRICE  <<< 

289 

290 

IF  mnet_price  >  price  *  { (model->history1/100)+1 ) 

291 

STORE  .T.  TO  mhistoryl 

&&  Set  history  flag 

292 

E»iDIF 

293 

ELSE 

&&  If  NSN  is  not  on  file 

294 

IF  mnet_price  >  mode1->history2 

&&  If  unit  price  exceeds  limits 

295 

STORE  .T.  TO  mhistory2 

&&  Set  history  flag 

296 

ENDIF 

297 

END  IF 

&&  -  of  history  check 

298 

299 

300 

301 

***  FILL  MEMORY  VARIABLES  ******************************%*** 

302 

t 

* 

303 

*  The  data  contained  in  the  hold  data 

file  is  next  organized  * 

304 

*  for  display.  This  is  accomplished  by  loading  a  matrix  of  * 

305 

♦  memory  variables. 

* 

306 

* 

* 

307 

im*ititt**i(****t****t**t**t********t*itt***%****t*****i*****t*** 

308 

309 

*  >>>  PLACE  DATA  IN  MEMORY  'MATRIX' 

<<< 

310 

311 

SELECT  C 

&&  Select  alternate  work  area 

312 

USE  hold  INDEX  h_ord_q 

&S  Activate  HOLD. DBF 

313 

GO  TOP 

SS  Set  pointer  to  first  record 

314 

315 

STORE  ord_quant  TO  morder! 

ii  Fill  first  matrix  unit 

316 

STORE  ord_quant  TO  mlast_ord 

&&  Store  for  program  control 

317 

STORE  cage  TO  mcagel 

84  Fi 11  first  matrix  unit 

318 

STORE  ext_price  TO  mext_l_l 

44  Fill  first  matrix  unit 

319 

STORE  ext_price  TO  mext_pr’ce 

44  Store  for  orogram  control 

320 

321 

STORE  1  TO  mrow 

44  Initialize  pointer  variable 

322 

STORE  1  '0  mcolumn 

44  Initialize  pointer  variable 

323 

324 

SKIP 

44  Move  oointer  to  next  record 

325 

326 

DO  WHILE  .NOT.  EOF() 

44  Fill  matrix  until  EOF  is  reache 

326 

d 
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327 

328 

329 

330 

331 

332 

333 

334 

335 

336 

337 

338 

339 

340 

341 

342 

343 

344 

345 

346 

347 

348 

349 

350 

351 

352 

353 

354 

355 

356 

357 

358 

359 

360 

361 

362 

363 

364 

365 

366 

367 

368 

369 

370 

371 

371 

372 

373 
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*  >>>  MOVE  TO  NEXT  COLUMN  <<<  If  not  the  same 


&&  Advance  column 
&&  End  of  display? 
&&  if  so,  terminate 


STORE  mcolumn  +  1  TO  mcolumn 
IF  mcolumn  =  7 
EXIT 
ENOIF 

STORE  'MOROER’+LTRIM{STR(fflcolumn))  TO  mcell 
STORE  ord_quant  TO  imcell 

STORE  ord_quant  TO  mIast_ord  Update  order  quantity 

ENOIF 

*  >>>  FIND  PROPER  ROW  <<< 

STORE  1  TO  mrow  &&  Reset  row 

STORE  .F.  TO  mflag  &&  Program  control 

DO  WHILE  .NOT.  mflag  &&  Look  for  row  with  matching  cage 

STORE  'MCAGE'+LTRIM(STR(mrow))  TO  mcage 
IF  Smcage  :  cage  .OR.  &mcage  = 

STORE  .T.  TO  mflag  &&  Set  flag  when  found 

ELSE 

STORE  mrow  +  1  TO  mrow  &&  Advance  to  next  row 

ENOIF 
ENDDO 

S''’0RE  cage  TO  Smcage 

STORE  'MEXT_'+LTRIM(STR(mrow))+’_’+LTRIM(STR(mcolumn))  TO  mec 
STORE  ext_price  TO  Smep 

SKIP  &S  Advance  record  pointer 

ENOOO  !i4  End  of  filling  memory  matrix 


♦**  REMOVE  HIGH  QUANTITY  VENDORS  t*tt**t***tti**t**t****t*t* 
*  * 

*  This  code  examines  the  quantity  offered  by  the  vendors  and  * 

*  removes  those  vendors  who's  lowest  quantity  offered  was  so  * 

*  large,  they  did  not  make  it  into  the  memory  matrix.  * 

*  * 
***t*tt*t********i***t*************t***:tt***tt******t**t******t* 

*  )>>  REMOVE  HIGH  QUANTITY  VENDORS  <<< 


IF  morderS  )  0 
led 

SELECT  or_temD 
GOTO  TOP 


&&  Not  needed  if  matrix  is  not 

&&  Activate  PR_TEMP.DBF 
i&  Set  pointer  to  first  record 
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374 

375 

375 

376 

377 

378 

379 

379 

380 

381 

382 

383 

384 

384 

385 

386 
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DO  WHILE  .NOT.  £OF()  Examine  entire  file 

IF  qminl  >  morderS  QMIN1  greater  than  largest  in 

he  matrix 


DELETE 
END  IF 
SKIP 
ENDDO 


Mark  vendor  for  deletion 

Advance  pointer  to  next  record 
&&  Repeat  until  End-Of-File  is  rea 


ched 


END  IF 


ii  End  high  quantity  test 


RETURN  &&  Return  control  to  calling  progr 

am 

»:  EOF:  PREPVEN.PRG 
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23 

24 

25 

26 

27 

28 
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31 
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34 

35 
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ttt**t***********tt****tt*********t*t*****t*t**%t******t**********t** 

Program:  SCREENS. PRG 

System:  Automated  Vendor  Selection  Assistant 
Author:  Capt  Daniel  E.  Hagmaier 
Copyright  (c)  1991,  United  States  Air  Force 

Called  by:  AVSA.PRG 

Uses:  NSN.DBF 

VENDOR. DBF 
DCRL.DBF 
DCRLCODE.DBF 
MODEL. DBF 
CDCF.DBF 


^age 


Indexes 


NJSN.NDX 
V_C_M I L . NDX 
DCR_CAGE . NDX 
CDCF  N  C.NDX 


Documented:  7/30/91 


11:35 


SNAP!  version  1.73 


*$t****t**t$$**$t**$t*ttt**tt$***tit*t***t*t***t**t*tt****tt*t****%tt 


tt********tt****t*-t**ttt*f*tt*t****t*t******t**tf»**t*t***t*tt*tt 
*  * 

*  This  IS  a  procedure  file  containing  the  display  screens  for  * 

*  user.  The  coding  herein  obtains  the  user's  incuts,  and  * 

*  performs  the  necessary  validation  on  those  inputs.  * 

*  * 
tt*t**t****H****t*t*****ttt**i****ttt*t**t**********t*itt***t**t 


***  TITLE  SCREEN  $*$*$$t*$$*******$$*$**tt****$*$$**$*t$$*t*$ 

«  * 

*  This  screen  is  the  log-on  screen  for  the  program.  ♦ 

»  ♦ 

tti»t**$mx*i*$i*H*t***$$$$$$Hi$*Ht$tttt**t*t**it********$*** 

PROCEDURE  I'ltleScr  &&  Labels  this  dock  of  code 

CLEAR  &&  Erases  the  screen 


*  )>>  CREATE  THE  SCREEN  <<< 


1 
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49 

50  @  0,0  TO  22,79  DOUBLE  Draws  box  around  screen 

51  @  2,32  SAY  "Welcome  To  The"  &&  Print  text  to  the  screen 

52  e  6,30  SAY  "AUTOMATE  D" 

53  @  8,33  SAY  "V  £  N  D  0  R" 

54  @  10,30  SAY  "S  E  L  E  C  T  1  0  N" 

55  @  12,30  SAY  "A  S  S  I  S  T  A  N  T" 

56  §  16,31  SAY  "3eta  Version  2.5"  ■ 

57  @  23,26  SAY  "Press  Any  Key  To  Continue" 

58 

59 

60  *  >>>  WAi'^  FOR  USER'S  RESPONSE  <<< 

6' 

62  WAIT  ""  8ii  Wait  for  keypress 

63 

64  RETURN  2i&  Return  control  to  calling  progr 

64  am 

65 
6F 
67 

6£  ***  PROGRAM  INFORMATION  SCREEN  **t**$*********$***tt*4t*t$*t* 


69  *  * 
7r  *  This  screen  describes  the  program  and  allows  the  user  to  * 
V  *  exit  the  program  if  desired.  * 

7  *  '  * 


'3  ««*s«*««««*«««i$««««<««**«*«*«««t«««*«t«*<««***«»«*****»«****«»** 


PROCEDURE  lnfo_Scr  S&  Labels  this  block  of 

1 5 

7'  CLEAR  S&  Erases  the  screen 

71  SET  COLOR  '0  G/B  &S  Insures  colors  are  set  oroper'y 

7i 

S. 

E'  *  >>)  CREATE  the  SCREEN  xv 


O'  I’EX”  &&  Following  is  sent  to  the  screen 

fc: 

8  I  ’he  Autom.ated  Vendor  Selection  Assistant 


8 

8£ 

89 

90 

91 
9; 

93 

94 

95 


select"  the  vendor(s)  who  have  competitively  bid 
on  the  item  of  interest. 

to  oroceed.  you  must  know  the  item's  NSN 
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96 

97 

98 

99 

100 
10! 
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’03 

104 

105 

106 

107 

108 

109 

110 
111 
112 
113 
’14 
115 
1’6 

117 

118 

119 

120 
121 
122 
123 

123 

124 

125 
’26 

127 

128 

129 

130 

131 
’32 

133 

134 
’35 
'36 
’37 
’38 
’39 
140 
'4' 
’42 


ENOTEXT 

@  0,0  TO  23,79  DOUBLE 


Do  you  wish  to  continue?  <Y/N> 

&&  End  text  sent  to  the  screen 
&&  Draws  box  around  the  screen 


*  >>>  GET  THE  USER’S  INPUT  <<< 

SET  COLOR  TO  3/8 
SET  INTENSITY  OFF 
STORE  'y'  to  .mchoice 
@  24,55  GET  mchoice  PICTURE  "Y" 

READ 

SET  INTENSITY  ON 
SET  COLOR  TO  G/9 
CLEAR 

RETURN 

am 


Hide  orompt 
&&  Hide  prompt 
&&  Make  ’Yes’  the  default 
i&  Accept  only  (Y>  or  <N> 

Activate  the  GET 
S&  Enable  highlighted  prompt 
&&  Restore  screen  to  normal 
SS  Clear  the  screen 

&&  Return  control  to  calling  progr 


**  INPUT  SCREEN  «*«««**«*«<««*«««*****«***<***«*«******<**** 

* 

This  section  prompts  the  user  for  the  NSN,  quantity  desired,* 

* 

* 


and  set-aside  information.  The  inputs  are  validated  and 
returned  to  the  master  crogram  via  the  memory  variables 
'MNSN',  ’MOUANTITY’ ,  and  'MSETASIOE'  respectively.  Ul, 
’Unit  of  issue),  is  a  field  from  the  VENOCR>DBF.  This 
screen  mav  be  terminated  before  entering  quant'ty  by 
Dressing  <ESC><ESC>. 


* 
* 
* 
* 

tt******tt***ttt*ttttt*tt*ttttxt**t**tttt**t*ttttt****tt*t*t*ttt 


f’RCCEDURE  :''CutScr 


SS  :.3bels  this  block  of  code 


DECLARE  -CCAL  VAR'ABlES 


■:(<: 
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143 

144 

STORE  .F.  TO  mvalid 

ii  True  when  NSN  is  valid 

145 

STORE  0  TO  mtime 

ii  Current  system  time 

146 

STORE  0  TO  mstop 

Stop  time  for  delay 

147 

STORE  0  TO  mcurrent 

Current  time 

148 

STORE  0  TO  mquantity 

44  Amount  of  product  requested 

149 

150 

151 

1  ^  0 

* 

>>>  PREPARE  THE  WORK  AREA  <<< 

153 

CLEAR 

44  Erases  the  screen 

154 

SELECT  A 

44  Activate  primary  work  area 

155 

USE 

nsn  INDEX  n_nsn 

44  Used  to  validate  the  NSN 

156 

SELECT  B 

44  Activate  alternate  work  area 

157 

USE 

vendor  INDEX  v_c_mil 

44  Used  to  obtain  Unit  Of  issue 

158 

SELEC^  A 

44  Activate  primary  work  area 

159 

SET 

RELATION  TO  cage+mi l_spec  INTO  vendor 

44  Link  VENDOR. DBF  with  PRICE. DBF 

160 

SET 

ESCAPE  ON 

44  Enable  the  (ESC)  key 

16' 

ON  i 

ESCAPE  DC  rturn 

44  Returns  control  to  calling  crog 

’61 

'■am 

'62 

163 

164 

« 

>))  CREATE  THE  SCREEN  <<< 

165 

166 

@  23.20  SAY  "Press  (ESCXESC)  to  Quit  the  Assistant" 

167 

9  0.0  TO  14,79 

44  Draw  Box 

168 

§  *4,26  SAY  "(Press  <CR)  when  complete)" 

44  Print  on  screen 

169 

1  J 

171 

*  7*^ 

* 

>V  ENTER  i  VALIDATE  "HE  NSN  <<< 

'73 

S^ORE  ,F.  -^0  mval  Id 

44  Set  program  control  f’ag 

174 

DO  ' 

WHILE  .NOT,  mvalid 

44  Do  until  NSN  is  correct 

'75 

@  2,19  SAY  "Enter  the  NSN  of  the  item  to  be  orocured" 

176 

@  5.31  GET  mnsn  PIC"UR£  "9999-99-999'9999" 

44  Enter  the  NSN 

’77 

READ 

44  Activate  GE"  command 

178 

SEEK  mnsn 

44  Search  for  NSN  in  PRICE. DBF 

119 

■P  FOUNDO 

44  1 f  NSN  is  valid 

180 

STORE  .T.  TO  mval id 

44  Set  the  control  flag 

'8' 

C'  '  ■ 

44  I f  NSN  IS  not  valid 

i 

'33 

t 

D.  SPLAY  WARNING  (<< 

184 

'35 

’  CHRC; 

44  Ring  the  bel 1 

186 

SET  COLOR  TO  R*/S 

44  Bl inking  red 

'87 

@9,28  SAY  "This  NSN  is  not  on  file" 

44  Print  on  screen 

'88 

SE"  COLOR  TO  G/9 

44  Return  screen  to  norma’  color 

189 
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190 

191 

192 

♦  >>>  TIMER  LOOP  <<< 

STORE  TIMEO  TO  mtime 

Current  system  time 

193 

mstop  :  VAL(SUBSTR(mtime,l,2))»3600+; 

194 

VAL(SUBSTR(mtime,4,2))«60+; 

195 

VAL(SUBSTR(mtime,7.2)}+5 

&&  Time  +  5  seconds 

196 

00  WHILE  mcurrent  <  mstop 

&4  Repeat  loop  until  stop  time 

197 

STORE  TIMEO  TO  mtime 

&&  Check  current  time 

198 

mcurrent  =  VAL(SUBSTR(mtime, 1 

l,2))»3600+: 

199 

VAL(SUBSTR(mtime,4,2))»60+; 

200 

VAL(SU9Si'R(mtime,7,2)) 

201 

ENDOO 

&& 

End  timing  loop 

202 

@  9,5  CLEAR  TO  9,75 

&& 

Remove  blinking  message 

203 

END  IF 

&& 

End  warning  routine 

204 

ENDOO 

&& 

End  input  NSN  routine 

205 

206 

207 

208 

*  >>>  CANCEL  ESCAPE  KEY  <:( 

209 

210 

9  23,0  CLEAR 

&& 

Remove  <ESC>  message 

211 

ON  ESCAPE 

&& 

Deactivate  on  escaoe 

212 

SET  ESCAPE  OFF 

&& 

Disable  escaoe  key 

213 

214 

215 

216 

217 

218 

♦  >>>  ENTER  &  VALIDATE  THE  QUANTITY 

(<< 

9  23.29  SAY  'Enter  <0><CR>  'o  Quit' 

&& 

Disolay  message  on  screen 

219 

9  9,26  SAY  "Enter  the  quantity  required" 

220 

9  12,42  SAY  vendor->ui  +  " 

&& 

Unit  of  issue 

221 

9  12,36  GET  mquantity  PICTURE  '9Z  99999’ 

&& 

Get  quantity 

222 

READ 

&& 

Activate  GET  conmand 

223 

224 

IF  mquantity  =  0 

&& 

Check  for  'Quit'  'nput 

225 

STORE  'Q'  TO  mchoice 

&& 

Set  memory  variable 

226 

RETURN 

&& 

Return  to  calling  program 

227 

END  IF 

228 

229 

9  23.0  CLEAR 

&& 

Remove  'Quit'  message 

230 

231 

232 

233 

*  '>>'•  ENTER  THE  ROD  DATE  <<< 

234 

235 

9  18,26  SAY  'What  -S  the  ROD  Cate’’ 

&& 

Promot  for  the  ROD  date 

236 

STORE  "C  mva’'d 

&& 

Reset  mVal :d  flag 

237 

DO  WHr_E  .NOT.  mval'd 

A-;o 
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238 

STORE  .T.  TO  mvalid 

i&  Set  mVal id  flag 

239 

@  18,48  GET  mrdd  PICTURE  '@Z  99999' 

Get  the  date  from  the  user 

240 

READ 

&&  Activate  the  GET  command 

241 

242 

*  >))  VALIDATE  THE  ENTRY  <<< 

243 

244 

IF  i NT(nirdd/1000)  <  (myear-(  !NT(myear/100)*100))-l 

245 

STORE  0  TO  mrdd 

Clear  the  mRDD  variable 

246 

STORE  .F.  TO  mvalid 

&&  Reset  the  mVal  id  i^’ag 

247 

END  IF 

248 

:F  mrdd-{( lNT(mrdd/1000))*100Q)  >  366  .OR. 

mrdd-({ INT(mrdd/1000))*1000)  < 

249 

STORE  0  TO  mrdd 

&&  Clear  the  mROD  variable 

250 

STORE  .F.  TO  mvalid 

Reset  mVal id  flag 

251 

END  IF 

252 

ENDDO 

253 

254 

*  >>>  ENTER  i  VALIDATE  SET-ASIDE  INFO  <<< 

255 

256 

SET  CONFIRM  OFF 

W  Enable  auto  advance 

257 

STORE  '  ’  TO  msetaside 

&&  Reset  variable 

258 

@  18,10  SAY  "Is  this  procurement  Set-Aside  for 

small  ; 

259 

business?  <Y/N/’>" 

Print  prompt  on  screen 

260 

DO  WHILE  msetaside  <>  "Y"  .AND.  msetaside  (>  "N 

1" 

261 

@  18,69  GET  msetaside  PICTURE  "1" 

&&  Convert  input  to 

262 

READ 

Activate  GET  command 

263 

msetaside  =  I lF(msetaside  =  "’"."N", msetaside) 

264 

ENODO 

265 

266 

SET  INTENSITY  OFF 

&&  Disable  highl ighted 

267 

268 

RETURN 

3i&  Return  control  to  calling  oi 

268 

am 

269 

27C 

271 

2'2 

***  SELECTING  VENDOR  SCREEN  ****t******»*»**#**»**»*»****«»*» 

273 

« 

* 

274 

*  "^his  screen  alerts  the  user  to  the  fact  that  the  system  is  * 

275 

*  'n  the  process  of  selecting  vendors  from  the  database.  * 

276 

« 

* 

277 

0  Q 

«*«t*«*****t«««*t*****«*t*t««*«*«***«*t*«****«*****«t*«*****»***« 

2 1  3 

279 

PROCEDURE  SelctScr 

ii  Label  this  block  of  code 

280 

281 

CLEAR 

is  Clear  the  screen 

282 

283 

§  6,27  TO  10,49  DOUBLE 

&&  Draw  box 

284 

@  8,30  SAY  'Selecting  Vendors' 

a  Print  message 
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285 

286 

RETURN 

Return  control  to  calling  progr 

286 

am 

287 

288 

289 

290 

NO  QUALIFIED  VENDER  SCREEN  *»«*****»»*»****»*»*$»**4***** 

291 

* 

♦ 

292 

*  This  screen  alerts  the  user  of  the  condition  in  which  no  * 

293 

*  aual if  led  vendors  exist. 

* 

294 

« 

* 

295 

tt******t*tt***t******tttt*ttt*************ttttt*tt*t*ttt***tt*** 

296 

297 

PROCEDURE  NoVenScr 

44  Label  this  block  of  code 

298 

299 

300 

*  >)>  INFORM  USER  <<< 

301 

302 

CLEAR 

44  Clear  the  screen 

303 

?  CHR(7) 

44  Ring  the  bel  1 

304 

SET  COLOR  ■'O  R^/B 

44  Set  color  to  blinking  red 

305 

@  5,26  TO  13,53  OOU8LE 

44  Draw  box 

306 

307 

SE"  COLOR  TO  G/B 

44  Return  color  to  normal 

308 

@  7,30  SAY  'No  qualified  vendors' 

44  Print  message  on  screen 

309 

@  9,30  SAY  'are  on  file  matching' 

310 

@  11,31  SAY  'your  reou irements . ' 

311 

@  14.27  SAY  'Press  Any  Key  To  Continue' 

31. 

313 

3U 

*  >>>  WAIT  roR  USER'S  INPUT  <<< 

315 

316 

WAIT  "" 

44  Wait  for  user  to  acknowledge 

317 

318 

STORE  .F.  '0  mnew_nsn 

44  Set  program  control  flag 

319 

320 

RETURN 

44  Return  control  to  calling  progr 

320 

am 

321 

322 

323 

324 

***  PRICE  SCREEN  t***t***t********ttt**i*t*****t***t***$*tt*t 

325 

t 

* 

326 

*  This  screen  displays  the  vendor(s) 

and  their  pricels)  for  * 

327 

*  the  item  requested  by  the  user,  it 

IS  used  for  both  unit  * 

328 

*  pricing  as  well  as  extended  pricing 

based  on  the  mUNIT_PR  ♦ 

329 

*  flag. 

* 

330 

< 

* 
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331  ttt*t*t*t*******t*t****tttt**t*tt$*****ttt*tttt*t****t*t**t****** 

332 

333  PROCEDURE  PriceScr  44  Labels  this  block  of  code 

334 

335  CLEAR  44  Clear  the  screen 

336  SET  COLOR  TO  G/B  44  Set  colors  to  standard  values 

337 

338 

339  *  >>)  DRAW  GRID  <<< 

340 

341  §  4,3  TO  22,75  DOUBLE  44  Draw  boxes  and  lines 

342  @  6,3  TO  6,75  DOUBLE 

343  @  ^0,3  TO  10,75 

344  §  14,3  TO  14,75 

345  §  18,4  TO  18,75  DOUBLE 

346  @  4,9  TO  18,9 

347  §  4,20  TO  18,20 

348  @  4,31  TO  18,31 

349  §  4,42  TO  22.42 

350  @  4,53  TO  18,53 

351  9  4,64  TO  18,64 

352 

353  @  4,9  SAY  CHR(209)  44  Special  characters  at  'rtersect 

353  ions 

354  @  4,20  SAY  CHfl(209) 

355  @  4,31  SAY  CHR{209) 

356  I  4,42  SAY  CHR(209) 

357  @  4,53  SAY  CHR(209) 

358  §  4,64  SAY  CHR(2091 

359 

360  @  18,9  SAY  CHR(207) 

361  §  18,20  SAY  CHR(207) 

362  #  18,31  SAY  CHR(207) 

363  @  18,42  SAY  CHR(216) 

364  §  22,42  SAY  CHR(207) 

365  @  18,53  SAY  CHR(207) 

366  @  18,64  SAY  CHR(207) 

367 

368  i  6,3  SAY  CHR{2041 

369  9  10,3  SAY  CHR{199} 

370  @  U,3  SAY  CHR( 199) 

371  9  18,3  SAY  CHR(204) 

372 

373  9  6,75  SAY  CHRf  185) 

374  9  '0,75  SAY  CHR( 182) 

375  9  ’4,75  SAY  CHR(  182) 

3"6  a  '3,75  SAY  CHRf'351 
377 
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378  @  6,9  SAY  CHR(216) 

379  §  6,20  SAY  CHR(216) 

380  @  6,31  SAY  CHR(216) 

381  @  6,42  SAY  CHR(216) 

382  @  6,53  SAY  CHR(216) 

383  §  6,64  SAY  CHR(216) 

384 

385  §  10,9  SAY  CHR(197) 

386  9  10,20  SAY  CHR(  197) 

387  @  10,31  SAY  CHR(197) 

388  9  10,42  SAY  CHR(197) 

389  9  10,53  SAY  CHR(197) 

390  9  10,64  SAY  CHR{197) 

391 

392  9  14,9  SAY  CHR(  197} 

393  9  14.20  SAY  CHR(197) 

394  9  14,31  SAY  CHR(  197) 

395  9  14.42  SAY  CHR(197) 

396  9  ’4,53  SAY  CHR(  197) 

397  9  14.64  SAY  CHR( 197) 

398 

399  :F  mhist_date  <> 

400  9  0,49  TO  1,49  DOUBLE 

401  9  2,49  TO  2,74  DOUBLE 

402  9  0,75  TO  1,75  DOUBLE 

403 

404  9  2,49  SAY  CHR(200) 

405  9  2,75  SAY  CHR(  ’88) 

406  ENO'F 
4CT 

108  ">  DISPLAY  CONSTANT  ITEMS  <;':v 

409 

410  iF  .NOT.  ,Tiun’t_pr  &&  L^st  user  octions 

4”  9  23,3  SAY  'i  ■  Unit  Pricing’ 

412  ELSE 

413  9  23.3  SAY  '  £<tended  Pricng' 

414  end;'" 

4^5 

4'6  9  24,3  SAY  '(  ^  Vendor  information' 

41’  9  23,30  SAY  '<  )  Award  Screen' 

413  9  24,30  SA^  ’ ;  >  Qu’f 

4‘9  9  23,55  SAY  '<  >  CDCF  Vendor  Deta’’’ 

420  9  24.55  SAY  ’  '  o-Qbign,  vendor  Detail’ 

42' 

422 

423  -  .L  N  ^EY  CODES  \ 

424 

425 
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426 

SET  COLOR  TO  BG+/B 

427 

IF  .NOT.  munit_pr 

428 

a  23,4  SAY  'U' 

429 

ELSE 

430 

@  23,4  SAY  'E‘ 

431 

END  IF 

432 

@  24,4  SAY  'V' 

433 

§  23,31  SAY  'A' 

434 

i  24,31  SAY  'O' 

435 

@  23,56  SAY  'C' 

436 

@  24,56  SAY  'P' 

437 

438 

*)>>  LABEL  SCREEN  <<( 

439 

440 

SET  COLOR  TO  G/B 

44’ 

iF  Tiunit_or 

442 

a  3,0  SAY  "Unit  Pricing 

Data  For: 

443 

ELSE 

444 

§  3,0  SAY  "Extended  Pric 

ing  Data  Foi 

445 

END  IF 

446 

SET  COLOR  TO  BG+ZB 

447 

@  3,$  SA'^  mnsn 

448 

449 

*>>>  PRINT  HISTORY  DATA  : 

/  / 

450 

451 

IF  mh'st.date  <)  ’  ' 

452 

SET  COLOR  TO  Q/B 

453 

@  0,51  SAY  'Last  Purchased  On 

454 

@  $,$  SAY  mhist_date  °IC 

|’■UR£  'XXXXX 

455 

9  $+1,51  SAY  'From 

456 

9  $,$  SAY  mhist_cage 

457 

9  $,$+1  SAY  'For  $' 

458 

9  $,$  SAY  mhist_or  PICT'J 

RE  '9B  9999 

459 

ENDI'^ 

460 

46' 

3RINT  COLOR  CODES  :< 

( 

462 

'3 

SET  COLOR  TO  G/3 

464 

9  19,5  SAY  'VENDOR:' 

465 

9  19,44  SAY  'PRICE: ' 

466 

SET  COLOR  TO  R/B 

467 

9  19,12  SAY  CHR(2i9)  +  '  ■’rob! 

em  Vendor  ii 

468 

SET  CC.OR  TO  GR+/B 

469 

9  19,50  uAY  CHR( 2’9)+'  ^r-ce 

Hay  Be  To  I 

4": 

SET  COLOR  "O  RB/B 

1  , 

a  20,12  SAX  CHR(219)+'  COCF 

Vendor  nfo 

4?: 

SET  COLOR  TO  G+/B 

473 

9  20,50  SAY  CHR;2'9)*'  .ow  Price’ 

A-25 
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&&  Change  screen  color 
&&  Label  screen 


Change  screen  co'or 
&&  Print  NSN 


i f  history  data  on  f • ’e 
S3i  Set  screen  colors 
2.&  Display  data 
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474  @  21,12  SAY  CHR(219)+’  Quality  Vendor' 

475  SET  COLOR  TO  G/3  Return  to  normal  color 

476 

477 

478  *  >>>  DiSPLAY  ORDER  QUANTITIES  <<< 

479 

480  §  5,12  SAY  morderl  PICTURE  '9Z  99,999'  &&  Print  order  quantities 

481  a  5,23  SAY  ,-norder2  PICTURE  '@Z  99,999' 

482  @  5,34  SAY  morder3  PICTURE  '@Z  99,999' 

483  §  5,45  SAY  morder4  PICTURE  '@Z  99,999' 

484  9  5,56  SAY  morder5  PiC.'uRE  '@2  99,999' 

485  9  5,67  SAY  morderS  PICTURE  '@Z  99,999' 

486 

487 

488  *  )>>  DISPLAY  MEMORY  MATRIX  <<( 

489 

490  INITIALIZE  VARIABLES  <<( 


49' 

492 

STORE  1  ^0  mcounter 

&&  1  to  9 

493 

STORE  1  TO  mcount 

&&  1  to  3 

494 

STORE  7  TO  mrow 

4&  7  to  22 

495 

STORE  1 1  TO  mcolumn 

44  11  to  66  step  11 

496 

STORE  1  "0  mr-ol 

44  1  to  6 

497 

STORE  TO  mcontinue 

44  Program  control  flag 

498 

;:CRE  'MCAGEl'  TO  mcage 

44  First  matrix  item  to  be  disola' 

498 

ed 

499 

500 

SELECT  Dr_temc 

44  Activate  PRJEMP.DBF 

501 

DO  WHILE  mcontinue 

44  Do  for  all  matrix  cages 

502 

..flCATE  ^OR  cage  :  &mcage 

44  Find  matrix  cage  in  Hrt_'l'EMP.jS 

503 

504 

*  COLOR  CODE  VENDORS 

505 

506 

DO  CASE 

44  Check  flags 

507 

CASE  prob 

508 

SET  COLOR  TO  R/3 

44  Change  diso’ayed  color 

509 

CASE  cdcf 

510 

SE'  COLOR  TO  RB/3 

5 '  ‘ 

CASE  qual ity 

512 

SET  COLOR  TO  G^B 

5’3 

ENDCASE 

514 

515 

9  nnrov*,4  SAY  Jmcage 

44  Print  cage  to  screen 

516 

SET  COLOR  TO  G/B 

44  Restore  color  to  norma’ 

517 

518 

*  )>)  DISPLAY  prices 

5'9 

520 

DO  while  mcol  <  7 

44  Fill  the  6  screen  columns 
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521 

STORE  ■MEXT_'+'.TRIM{STR(mcounter))  +  '_‘<'LTRIM{STR(mco;))  TO  morice 

522 

523 

* 

)>)  COLOR  CODE  PRICES  <<< 

524 

525 

DO  CASE 

Test  price  flags 

526 

CASE  mlow  .AND.  &mprice  =  mlow_price 

527 

SET  COLOR  TO  GR+/B 

528 

CASE  &mprice  =  mlow_price 

529 

SET  COLOR  TO  G+7b 

530 

ENDCASE 

531 

532 

'f  munit_pr 

&&  Display  price  on  screen 

533 

STORE  ’MORDER’+LTRIM(STR(mcol))  TO  mordei 

534 

STORE  imprice/imorder  TO  mnet_orice 

535 

@  mrow.mcolumn- 1  SAY  mnet_price  PICTURE  '@2  9,999.9999' 

536 

ELSE 

537 

@  mrow.mcolumn  SAY  &mprice  PICTURE 

99,999.99' 

538 

END  IF 

539 

540 

Sc"  COLOR  TO  G/a 

541 

542 

t 

)>)  ADVANCE  COUNTERS  <<< 

543 

544 

STORE  mcolumn  +  11  TO  mcolumn  . 

&&  Increment  screen  oosition  count 

544 

er 

545 

STORE  mcol  +  1  TO  mcol 

&&  Increment  column  counter 

546 

ENDDO 

&&  Finish  one  row 

547 

548 

STORE  1 1  TO  mcolumn 

Reset  screen  oosition  counter 

549 

SI'ORE  ‘  TO  mcol 

&&  Reset  column  counter 

550 

STORE  mrow  1  TO  mrow 

&&  Advance  screen  oosition  counter 

551 

STORE  mcounter  +  1  TO  mcounter 

&&  Advance  matrix  counter 

552 

553 

* 

:■>>  CHECK  FOR  GRID  LINE  ;<( 

554 

555 

!F  mcou.nt  =  3 

&S  Don't  onnt  on  a  gi'id  line 

556 

STORE  mrow  +  1  TO  mrow 

&&  Advance  screen  oosition  counter 

557 

STORE  1  TO  mcount 

Advance  counter 

558 

ELSE 

559 

STORE  mcount  +  1  TO  mcount 

&&  Advance  counter 

560 

END  IF 

561 

562 

STORE  'MCAGE'+LTRm(STR{mcounter))  TO  mcage 

563 

IF  Simcage  :: 

564 

STORE  .F.  TO  mcontinue 

.F.  If  all  cages  disolayed 

565 

END  IF 

566 

END 

DO 

567 
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568 

569 

57Q  tt*:r**************Hf*******tu*************t********************* 


571  *  * 

572  *  The  following  code  checks  for  conditions  the  buyer  should  * 

573  ♦  be  aware  of  before  making  an  award.  * 

574  »  * 


575  tt*ti****ttt*$**t*****t*******ttt*******tt*ttt****t**tt***t*t*t** 

576 

577  *  >>>  CHECK  VENDOR  VARIATION  <<< 

578 

579  STORE  Q  TO  mline  &4  Display  row  counter 

580  IF  mvariation  &&  Check  for  variation  problem 

581  SET  COLOR  TO  R+*/B  44  Display  warning 

582  @  ml ine,0  SAY 

583  SET  COLOR  TO  G/B 

584  @  ml  me, $+3  SAY  'LOW  QUOTE  PLUS  VARIATION  EXCEEDS  $' 

585  @  mline.S  SAY  LTRIM{STR(model->up_l imit, 10,2)) 

586  SET  COLOR  TO  R+*/B 

587  @  mime, $+3  SAY  ’***' 

588  SET  COLOR  TO  G/B 

589  STORE  mline  +  1  TO  mline  44  Advance  row  counter 

590  ENDIF 

591 

592 

593  *  >>>  CHECK  HISTORICAL  DATA  <<< 

594 

595  IF  mhistoryl  44  Check  high  once  for  history 

596  SET  COLOR  ’’0  R+*/B  44  Display  warning 

597  a  ml  me,0  SAY  '***' 

598  SET  COLOR  TO  G/B 

599  @  $,$+3  SAY  'UNr  PRICE  EXCEEDS  HISTORY' 

600  SET  COLOR  TO  R+*/B 

601  @  $.$+3  SAY  '«*■ 

602  STORE  mlme+1  to  mime 

603  ENDIF 

604 

605  IF  mhistory2  44  Check  no  history  on  NSN 

606  SET  COLOR  TO  R+*/B  44  Display  warning 

607  @  ml  me,0  SAY  '***' 

608  SET  COLOR  TO  G/B 

609  §  m'me.$+3  SAY  'UNIT  PRICE  OVER  $' 

610  9m’me,$+1  SAY  LTRiM(STR{model->history2, 10,2)) 

611  @  mIme,$Yl  SAY  'WITH  NO  HISTORY' 

612  SET  COLOR  TO  R+VB 

613  §  ml me,i+3  SAY  '***' 

614  SET  COLOR  TO  G/B 

615  ENDIF 
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616 

617 

618 

*  >)>  GET  USER'S  RESPONSE  <<< 

619 

620 

STORE  '  '  TO  mchoice 

&&  Reset  user's  choice  variable 

621 

SET  OOLOR  TO  B/B 

622 

!F  munit_pr 

623 

STORE  'U'  TO  mreturn 

&&  Flag  for  user  to  return  to  this 

623 

screen 

624 

DO  WHILE  .NOT.  UPPER(mchoice)$'AC£PQV' 

&&  Limit  user's  response  choices 

625 

WAIT  ' '  TO  mchoice 

&&  Get  response 

626 

ENDDO 

627 

ELSE 

628 

STORE  'E'  TO  mreturn 

&&  Flag  for  user  to  return  to  this 

628 

screen 

629 

DO  WHILE  .NOT.  UPPER{mchoice)$' APQUV 

&&  Limit  user's  response  choices 

630 

WAIT  "  TO  mchoice 

a  Get  response 

631 

ENDDO 

632 

END  IF 

633 

SET  COLOR  TO  G/B 

634 

635 

STORE  .F.  TO  munit_pr 

&&  Reset  program  control  f’ag 

636 

637 

RETURN 

&&  Return  to  calling  crogram 

638 

639 

640 

641 

***  VENDOR  SCREEN  t****ttttt**t*tt*t***tt**tt***t*tt*tt*tt*tt 

642 

* 

t 

643 

*  This  screen  d’solays  the  vendor  data  for 

those  Qua.  ‘ed  * 

644 

*  vendors  competing  on  the  item  requested  by  the  user.  * 

645 

* 

t 

646 

tx*t*tt***tttt**t*i****tttttt*tttttttt*tt*ttt**t*tttttttt*tt**t*t 

647 

648 

PROCEDURE  VendrScr 

&&  Labels  th's  c'ocK  of  code 

649 

650 

CLEAR 

Clear  the  screen 

651 

SET  COLOR  TO  3/3 

SS  Set  color  to  standard  va^-^e 

652 

653 

654 

*  >>>  INSERT  TEXT  <<< 

655 

656 

@  2,50  SAY  'D  S  P  C  Q’ 

&&  ^'ace  text  or  the  screen 

657 

@  3,50  SAY  '  ■  N  0  F  P  R  D  U' 

653 

3  4,50  SAY  'S  E  E  0  E  0  C  A' 

659 

@  5,4  SAY  'CAGE  VENDOR' 

660 

3  5,50  SAY  'C  "  -  3  C  3  S  I.' 

66’ 
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662 

663 

664  *  >>>  DRAW  GRID  <<< 

665 

666  @  4,3  TO  4,47  DOUBLE  &&  Draw  boxes,  lines 

667  @  1,47  TO  18,47  DOUBLE 

668  @  1,47  TO  1,75  DOUBLE 

669  9  1,75  TO  18,75  DOUBLE 

670  9  4,3  TO  18,3  DOUBLE 

671  9  18,3  TO  18,75  DOUBLE 

672 

673  9  6,3  TO  6,75  DOUBLE 

674  9  10,3  TO  10,75 

675  9  14,3  TO  14,75 

676 

677  9  4,9  TO  18,9 

678  9  6,53  TO  18,53 

679  9  1,59  TO  18,59  DOUBLE 

680  9  1,65  '0  13,65 

681  9  1,67  TO  '8,67  DOUBLE 

682  9  1,69  TO  18,69 

683  9  1.71  TO  18,71 

684  9  1,73  1-C  18,73 

685 

686  9  4,3  SAY  CHR(201)  &&  ^lace  soecia!  characters  at  int 

686  ersections 

687  9  4,9  SAY  CHR(209) 

688  9  4,47  SAY  CHR( ’85; 

689  9  1,47  SAY  CHR(20') 

690  9  ’.59  SAY  CHR(203) 

69'  9  1.55  SAY  CHR{209) 

692  9  1,67  SAY  CHR{203) 

693  9  1.59  SAY  CHR(2991 

694  9  ',7'  SAv  CHR(2091 

695  9  1.73  SAY  CHR(2C9; 

696  9  ■ .75  SAY  CHR( 187) 

597 

698  9  18,3  SAY  CHR(200) 

599  9  '8.9  SAY  CHR(207) 

700  9  18.47  SAY  CHR(2C2) 

701  9  13.53  SAY  CHR(207) 

702  9  '8,59  SAY  CHR(202) 

703  9  '8,65  SAY  CHPfZO’l 

704  9  '8,67  SAY  CHRf202) 

*05  a  18,69  SAY  CHR(2071 

706  9  '8,7'  SAY  CHR(207) 

707  9  'S.n  SAY  CHR(  207  ) 

708  9  18,75  SAY  CHR('88) 
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709 

710  @  G,3  SAY  CHR(204) 

711  @  10,3  SAY  CHR(199) 

712  @  14,3  SAY  CHR( 199) 

713 

714  @  6,75  SAY  CHR( 185) 

715  @  10,75  SAY  CHR(182) 

716  @  14,75  SAY  CHR(182) 

717 

718  @  6.9  SAY  CHR(216) 

719  @  6.47  SAY  CHR(206) 

720  @  6,53  SAY  CHR(209) 

72’  @  6,59  SAY  CHR(2C6) 

722  @  6,65  SAY  CHR(216) 

723  9  6,67  SAY  CHR(206) 

724  @  6,69  SAY  CHR(216) 

725  9  6,71  SAY  CHR(216) 

726  9  6.73  SAY  CHR(216) 

727 

"28  9  10,9  SAY  CHR{197) 

729  9  10,47  SAY  CHR(215) 

730  9  10,53  SAY  CHR(197) 

731  9  10,59  SAY  CHR(215) 

732  9  10,65  SAY  CHR(197) 

733  9  10,67  SAY  CHR(215) 

734  9  10,69  SAY  CHR( 197) 

735  9  10,71  SAY  CHR(i97) 

736  9  10,73  SAY  CHR(197) 

737 

738  9  14,9  SAY  CHR('971 

739  9  ’4,4"  SAY  CHR'2’5! 

740  9  14,53  SAY  CHR(197) 

741  9  ’4,59  SAY  CHR(215; 

"42  9  ’4,65  SAY  CHR{’97) 

'43  9  ’4.67  SAv  CHR;2’5: 

"44  9  14,69  SAY  CHR( 197) 

745  9  ’4,7’  SAY  CHR(’97: 

746  9  ’4.73  5A''  CHRf  ’9"' 

74' 


748 

"49  *  O'SPLAr  OP": CSS 

750 

75’  9  22,0  SAY  ''Use’‘'s  Octicns:"  H  Oisplay  user's  choices 

"52  9  23,3  SAY  '<  >  unit  Pricrg’ 

753  9  24,3  SAY  '<  >  Extended  Pricing’ 

754  9  23.30  SAY  '  :  „■  Award  Screen' 

755  9  24.30  SAv  '  >  O.’f 

756  9  23.55  SAY  '<  >  COCF  Vendor  Detail’ 
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757  @  24,55  SAY  '<  )  Problem  Vendor  Detail’ 


758 

759  SET  COLOR  TO  BQ+/3 

760  a  23,4  SAY  'U' 

761  @  24,4  SAY  'E' 

762  @  23,31  SAY  'A’ 

763  @  24,31  SAY  'Q' 

764  @  23,56  SAY  'C 

765  §  24,56  SAY  'P' 

766 

767  SET  COLOR  TO  G/B 

768  @  2,0  SAY  "Vendor  Data  For: 

769  SET  COLOR  TO  3G+/3 

770  @  2,$  SAY  mnsn 

771 

772 

773  ♦  >)>  FILL  SCREEN  <<( 

774 

775 

776  *'')>  :n:T’AL::E  COUNTERS  <<< 

777 

’73  S’CRE  1  ’0  mcounter 

779  STORE  ’  ’C  mcount 

730  S’ORE  7  ^0  mrow 

781 

782  *>>■  "'.ACE  DA’A  ON  SCREEN  < 

783 

784  SELECT  or  temo 


’36  S’CRE  ’0  mcontmue 
737  SEi"  COLOP  TO  G/B 
’38  DO  WHILE  mcontmue 
’89  L.CCATE  FOR  cage  ^  imcage 

790  DO  CASE 

791  CASE  prob 

F92  SE’  COLOR  TO  R/3 

793  CASE  cdcf 

794  SET  COLOR  TO  RB/B 

’95  CASE  quality 

796  SE’  COLOR  ’0  G+/B 

797  ENDCASE 

798  @  Tirow,4  SAY  Smcage 

799  SE’  COLOR  TO  G/B 

800  §mrow,10  SAY  vendor->name 


&&  Display  key  codes 


Return  color  to  normal 
&&  Title  screen 
Change  color 
&&  Print  NSN 


&&  Activate  ?R_’EMP.DBF 
&&  Create  cage  oomte-*  var-able 
&&  Set  program  control  fUg 
&&  Insure  normal  screen  color 
print  data 

&&  Find  mCAGEl  in  the  database 
&&  Check  for  h^ghl ights 


&&  Print  cage 

S&  Reset  color  to  normal 

8i&  Prmt  vendor  data 


80'  @  mrow,48  SAY  vendor- id’sc  PICTURE  '@Z  99.9%’ 

802  @  mrov«,54  SAY  vendor- idays  f’iCTURE  ’az  99’ 

803  @  mrow,56  SAv  ' /’ 

804  §  mrov(,57  SAY  vendor-', net  PICTURE  ’@Z  99' 


’35  SFORE  ’MCAGE'*L’R'«lS’P{mcounter))  ’0  mcage 
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805 

806 

807 

808 

809 

810 
811 
312 
813 
314 

815 

816 
817 
3’3 
819 
320 
82' 

322 

323 

324 
825 
326 
827 
823 

829 

830 

831 
332 

833 

834 

835 

836 

837 

838 

839 

840 

841 

842 

843 
344 

845 

846 

347 

348 
849 
350 
851 
352 
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Automated  Vendor  Selection  Assistant 
STORE  mj_date  +  vendor->de1  ivery  model->alt  TO  mdelivery 
STORE  yAL{RIGHT(STR{myear),2))  TO  myear 

IF  (myear*1000)+mde! ivery  >  mrdd  &&  Compare  delivery  date  to  ROD 

SET  COLOR  TO  R/B  &&  If  unable  to  meet 

ENDIF  44  Change  colors 

DO  CASE  44  Calculate  delivery  date 

CASE  .NOT.  mleao_yr  .AND.  mdelivery  <-  365 
§  mrow,60  SAY  myear  PICTURE  '@Z  99’ 

;  F  mdel  '.very  100 
@  mrov<,62  SAY  '0' 

I  mrow,63  SAY  mdelivery  PICTURE  '§Z  99' 

ELSE 

§  mrQw.62  SAY  mdelivery  PICTURE  '3Z  999' 

ENO’F 

CASE  .MOT.  mleao_yr  .AND.  mdelivery  >  365 
@  mrow,60  SAY  myear+l  PICTURE  '@Z  99’ 

; F  mdel ivery  -  365  <  100 
@  mrow,62  SAY  'O' 

9  mrow,63  SAY  mdelivery  -  365  PICTURE  ’@Z  99' 

ELSE 

@  mrow,62  SAY  mdelivery  -  365  PICTURE  '9Z  999’ 

ENDIF 

CASE  mIeao_yr  .AND.  mdelivery  <-  366 
@  mrow,60  SAY  myear  PICTURE  '§Z  99’ 

I F  mdel ivery  <  100 
@  mrow,62  SAY  '0' 

§  mrovi(,63  SAY  mde’ ivery  PICTURE  '@Z  99’ 

ELSE 

@  mrovi,62  SAY  mdelivery  PICTURE  '@Z  999’ 

ENOiF 

CASE  mleao_yr  .AND.  mdelivery  >  366 

9  mrow.60  SAY  myear*!  PICTURE  ’@Z  99' 

^  mdel ivery  -  366  <  100 
§  mrow,62  SAY  'O' 

9  mrow,63  SAY  mde' ivery  -  366  PICTURE  ’9Z  99' 

E.SE 

9  mrov».62  SAr  mde' 'very  -  366  PIC’URE  '9Z  999’ 

ENDIF 

ENDCASE 

SE’  COLOR  "0  G/B 
'Z')  PRINT  FLAGS  <  <  < 

9  mrow,S6  SAv  vendor->fob  PICTURE  ’!'  44  Display  F.O.3. 

IF  vendor-)size_code  <>  'A'  44  Small/’arge  vendor  flag 

9  mrov»,68  SAY  '  r  ’ 
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853 

END!' 

354 

!F  orob 

&&  Problem  vendor  flag 

855 

@  'nrow,7C  SAY  'X' 

856 

ENOIF 

857 

;f  cdcf 

&&  CDCF  Flag 

858 

9  mrow,72  SAY  'X' 

859 

ESD!F 

360 

! F  qual ity 

&&  Qual ity  flag 

861 

@  mrow,74  SAY  'X' 

362 

863 

END  IF 

864 

865 

*  >>)  ADVANCE  COUNTERS  <<< 

866 

STORE  mcounter  +  1  TO  mcounter 

&&  Advance  mCAGE#  counter 

867 

868 

STORE  mrow  1  TO  mrow 

Advance  print  row  counter 

869 

870 

»  >>>  CHECK  'OR  GRID  L'.NES  ■.<< 

371 

IF  mcQunt  -  3 

&&  if  t.hree  ’’nes  have  been  printe 

37* 

d 

372 

STORE  mrow  +  1  TO  mrow 

&&  Advance  row  counter 

873 

STORE  1  TO  mcount 

4&  Reset  counter 

374 

ELSE 

875 

STORE  mcount  +  1  TO  mcount 

44  Advance  counter 

875 

877 

ENDi' 

878 

STORE  'MCAGE'-H  ■'■R; Ml STR (mcounter))  TO  mcage 

879 

■F  imcage  : 

44  Check  for  ’ast  cage 

380 

STORE  .F.  ’O  mconfnue 

44  .F.  if  all  have  been  printed 

881 

END  IF 

882 

383 

884 

ENDDO 

385 

886 

*  )>)  WAIT  FOR  USER  RESPONSE  • 

387 

S'ORE  'V  TO  mreturn 

44  F’ag  ''or  ^ser  to  ^et..rn  to  this 

387 

screen 

388 

STORE  '  '  "0  mcho’ce 

44  Reset  user's  cho'ce 

339 

SE*  COLOR  ”0  3/B 

44  Hide  response 

390 

CC  WH^.E  .NOT.  UP°ER(mchoice)$'ACEPQU' 

44  -'mit  ..sen’s  -esponses 

89* 

WA  '  ' '  'C  mere :  ce 

44  Get  user ' s  response 

892 

ENDDO 

393 

894 

SE’  COLOR  ’0  G/9 

44  Return  screen  to  norma’ 

895 

RE'URN 

44  Return  control  to  ca'ling  progr 

395 

396 
897 

am 
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898 

899  ***  ANALYZING  VENDOR  SCREEN  ***t***t**t*****t***i****»***^*** 

900  »  * 

901  *  I'h’s  screen  alerts  the  user  to  the  fact  that  the  system  is  * 

902  *  in  the  process  of  analyzing  vendors  in  the  temporary  db.  * 

903  «  * 

0Q4  t««t«y«««««t«y«ty««y*««tt**»«:r***«********«««*»*>««**4ty««*«**«*** 

905 

906  PROCEDURE  AnalzScr  &&  Labels  this  block  of  code 

901' 

908  CLEAR  &&  Clear  the  screen 

909 

910  9  6.27  TO  10,49  DOUBLE  &&  Draw  box 

911  9  8,29  SAY  'Analyzing  Vendor(s)'  &&  Print  message 

912 

913  RETURN  Return  control  to  calling  progr 

913  am 

9'4 

915 

9’6 

giT  ***  NlTIALiZ'NG  SYSTE"^  SCREEN  ****»******»*#*»»***»*»**«*»*< 

918  *  * 

9’9  *  This  screen  alerts  the  -ser  to  the  ^act  that  the  system  -s  * 

920  *  in  the  process  of  ■n-t'al'Z’ng  the  system.  *  . 

921  *  * 

922  »*****«**»***»**»»»»»»»»***»***«$»»»*» t»»»**»**»t »»»»»*» 

923 

924  apoCEOURE  ImtlSc"  &S  Labels  this  clock  of  code 

925 

926  CLEAR  Clear  the  screen 

927 

928  9  5,26  TO  '0,51  DOUBLE  &&  Draw  box 

929  9  3,28  SA^  ’  I n ’t ;a’ iz  mg  ’’he  Svstem'  &&  Display  message 

930 

931  RETURN  S&  Return  control  to  C3”mg  progr 

931  am 

932 

933 

934 

935  *tt  opOBLEh  VENDOR  SCREEN  **ttt*tttttt***t**tt*t**ttttt**tttt 

936  *  * 

93"^  *  "h's  screen  displays  the  mformat'on  on  f’’9  m  DCRL  data  * 

938  *  base  for  a  selected  vendor.  * 

939  *  * 

94Q  t«*t«*«««***««*««w*s4****««*««««*t**«»x«t*******t***ftt**t**t*«*w 

941 

942  PROCEDURE  ^'■obmScr  S4  Labels  this  block  of  code 

943 
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944  @  23,0  CLEAR  &4  Clear  the  screen 

945  SET  COLON  TO  G/B  44  Set  color  to  normal 

946 

947  @  23,26  SAY  'Oisplay  Details  For:'  44  Display  user  instructions 

948  3  24,10  'Press  <SPACE  BAR)  For  Next  Choice  -  Any  Other  Key  To  Accept' 

949 

950 

95’  *  DISPLAY  CAGE  CODES  <<( 


952 

953  SELECT  or_temp 

954  LOCATE  FOR  prob 

955  GOTO  TOP 

956  SET  COLOR  TO  3G/B 

957  STORE  '  '  TO  mchoice 

958 

959  DO  WHILE  mchoice  :: 

959  ag 

960  ‘F  EOFll 

961  GOTO  TOP 

962  ENDIF 

963  CONTINUE 

964  IF  EOF;; 

964  d 

965  @  23,47  SAY  'No  One' 

966  ELSE 

967  I  23, 4T  SAY  cage  » 

968  LliD'F 

969  WAIT  ' '  ’'0  mchoice 

970  ENDDO 
97’ 

972 

973  *  :■>'  DISPLAY  USER'S  CHOICE 

974 

975  '■  EOFO 

976  STORE  mreturn  TO  mchoice 

976  crsen 

977  Else 

978  CLEAR 

979  SE*  COLOR  ’0  G/B 

980 

98’  *  DRAW  ’^lE  GRID  -.''I 

982 

933  §  A.3  -c  ’9.77  DOUBLE 

984  a  6,4  "0  6,76  DOUBLE 

935  @  '3.4  ’C  '3, ’6 

986  @  7,36  TO  12.36 

987 

988  SELEC^  C 


44  Activate  3R_''EMP.DBF 
44  Initialize  the  locate  command 
44  Return  to  the  first  record 
44  Change  screen  color 
44  Clear  user's  choice 

44  Display  vendors  with  orcb'em  *’ 

44  If  BOF, 

44  Go  to  Too  of  File 

44  Look  for  next  problem  -endor 
44  If  all  problem  vendors  disolaye 

44  Print  'No  One' 


44  Get  aser's  ‘rput 


44  User  picked  'No  One' 

44  Prepare  to  return  to  orevous  s 

44  Otherwise, 

44  Clear  the  screen 
44  Set  color  to  normal 


44  Draw  coxes,  1  ires 


44  Use  alternate  work  area 


A-36 


Page  22 


7/30/91  SCREENS. PRG 

11:42  Copyright,  United  States  Air  Force,  1991 

Automated  Vendor  Selection  Assistant 


989 

USE  dcrl  INDEX  dcr_cage 

&& 

Activate  DCRL. DBF 

990 

SELECT  0 

&& 

Use  alternate  work  area 

991 

USE  dcrlcode 

&& 

Activate  DCRLCODE. DBF 

992 

SELECT  DCRL 

&& 

Activate  DCRL 

993 

SEEK  or_temo->cage 

&& 

Look  for  cage 

994 

995 

9  5,37  SAY  cage 

&& 

Display  vendor  address 

996 

9  7,4  SAY  LEFT{namel,32) 

997 

§  $+1,4  SAY  LEFT(name2,32) 

998 

@  $+1,4  SAY  LEFT! names, 32) 

999 

@  $+1,4  SAY  LEFT(name4,32) 

1000 

^301 

SELECT  dcrlcode 

&& 

Display  problem  codes 

1002 

@  7,38  SAY  dcrl->datel  *  '  '  +  dcrl-)categoryl 

1003 

LOCATE  FOR  code  -  LEFT(dcr I->category 1 , 1 ) 

1004 

IF  FOUND!) 

*005 

§  $.50  SAY  title 

1006 

ENOIF 

1007 

@  $+1,38  SAY  dcrl->date2  +  '  ’  +  dcrl->category2 

1008 

LOCATE  FOR  code  :  LEFT!dcrl->category2, 1 ) 

*009 

IF  FOUND!) 

1010 

9  $,50  SAY  title 

1011 

END  IF 

1Q12  @  S+’l.OS  SAY  dcrl->date3  +  '  '  +  dcrl->categorv3 

10'3  LOCATE  FOR  code  :  LEFT(dcr!-)category3, 1) 

*014  IF  FOUND!) 

1015  @  $.50  SAY  title 

*0*6  ENOIF 

IQl"*  §  $*-',38  SAY  cc’-'dateA  +■  '  '  +  dcr!-'category4 

’O'S  lOCA’'E  -or  code  ::  '^E-'l  dc '-^categoryA,  1 ) 

1019  -OUNO(' 

1020  @  $.50  SAY  f t’e 

*32’  ENDIF 

!C22  §  $+1,38  SAY  dcr'-'  dateS  dcr  ;-:  category5 

’u23  LOCATE  FOR  code  =  LER‘'’(dcr  ’  - :  categoryS ,  " 

•324  fC'JNOf ) 


1025 

@  $.50  SAY  tit’e 

’026 

ENDIF 

+  Th  0  7 
•J  (.  ' 

@  $+'  .38  SAY  dcr’-''dat96 

dcr l->category6 

1028 

LOCATE  FOR  code  :  LEFTfdcrl 

->category6, 1 ) 

1029 

IF  FOUND!) 

1030 

@  $.50  SAv  t^+le 

103* 

END'F 

’032 

'333 

SElEv.1  dcrl 

a  Print  restriction  verb'age 

'034 

9  14,14  SAY  restrict! 

1035 

9  $+1,'4  SAY  ^estr-ctO 

1036 

9  $+1,14  SAY  restricts 
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’037 

a  $+ 1 , ’4  SAY  restr ict4 

1038 

@  $+1,14  SAY  restrict5 

1039 

1040 

STORE  .Tiretarn  '0  .Tichoice 

&&  Return  user  to  previous  screen 

1041 

%  23,0  SAY  '  ' 

&&  Position  cursor 

1042 

WAIT 

Wait  for  user  to  respond 

1043 

END  IF 

1044 

’045 

SELEC"  D 

Return  MODEL. DBF  to  area  D 

’046 

USE  MODEL 

S&  Activate  MODEL. DBF 

’047 

1048 

RETURN 

&&  Return  control  to  calling  progr 

’048 

am 

’049 

’050 

’05' 


’052 

*'**  CDCF  VENDOR  SCRE-N  *ttt*t**t**x*%tttttt***t**t**t-$ttt***t 

1053 

t 

S 

'054 

*  'h'3  3c:^een  disc’ay  t^e  '^fomat’on  or 

•  n 

CDCF  data  « 

'055 

*  base  ^or  a  se’ected  vender. 

t 

« 

t 

'053 

•059 

3RCCECURE  Cdc^Scr 

Labels  t.his  block  of  code 

•060 

•051 

3  23.0  CLEAR 

Clear  the  screen 

1062 

SET  COLOR  ’C  3,3 

Set  color  to  norma’ 

•063 

'054 

§  23,26  SAY  'Diso'ay  Ceta^’s  -or:' 

D'sp’ay  user  'nstruct'ons 

’065 

3  24,10  SAY  'P-ess  .SPACE  BAR--  For  Next  ChO'ce 

-  Anv  Otiier  Yey  "^o  Accept' 

'066 

•061’ 

'063 

«  DISPLAY  CAGE  CCDES 

•069 

♦  ■*  r> 

V  U 

SE^EC"  or_tenio 

i2i 

Activate  ”_*E^P.DBF 

’  3  **  * 

L.CCA"  -OR  cdc‘ 

'n’tialize  the  locate  coT-'a^o 

w  L 

3C'C  'CP 

Retar"  to  t'^e  '-^st  record 

•073 

SE'  COLOR  TO  SG/8 

&& 

Change  screen  color 

•ou 

’  7  ^ 

S'CRE  '  '  *C  'ncRo^CS 

e'ear  user's  choice 

*3^6 

DC  WH '  '^E  ncho'ce  ^ 

D'sc'ay  vendors  w^th  prob'em 

'076 

39 

-  n ; : 

IF  EOF(  1 

'f  3CF, 

•073 

GOTO  •'OP 

Go  to  Too  of  - 1 ’e 

•:t9 

END'^ 

'080 

CONTINUE 

&& 

Look  ^or  next  problem  vendor 

'08 ' 

-  EOP^  '■ 

‘  a’’  problem  vendors  diso’aye 

•38’ 

d 
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1082 

@  23,47  SAY  'No  One’ 

&&  Print  'No  One’ 

1083 

ELSE 

1084 

§  23,47  SAY  cage  +  '  ‘ 

1085 

END  IF 

1086 

WAIT  ’ '  TO  mchoice 

&&  Get  user's  input 

1087 

ENDDO 

1088 

1089 

1090 

*  >>>  DISPLAY  USER'S  CHOICE  <<< 

1091 

1092 

IF  EOF() 

&&  User  picked  'No  One' 

1093 

STORE  mreturn  TO  mchoice 

&&  Prepare  to  return  to  previous  s 

1093 

creen 

1094 

ELSE 

&&  Otherwise, 

1095 

CLEAR 

&&  Clear  the  screen 

1096 

SET  COLOR  TO  G/B 

&&  Set  color  to, normal 

1097 

1398 

*  >>>  DRAW  THE  GRID  <<< 

1099 

1100 

@  4,3  TO  13,77  DOUBLE 

&&  Draw  boxes,  1 ines 

1101 

§  6,4  TO  6,76  DOUBLE 

1102 

1103 

«  >>>  PRINT  THE  CONSTANTS  <<< 

1104 

1105 

SET  COLOR  TO  G+/B 

&&  Change  screen  color 

1106 

@  8,5  SAY  'DISC 

1107 

@  $+1,5  SAY  'CAUSE  ->' 

1108 

§  $+1,5  SAY  'DISP 

1109 

§  $+1,5  SAY  'CORR 

1110 

nil 

1112 

1113 

*  >>>  PRINT  THE  DATA  <<< 

SET  COLOR  TO  W/B 

&&  Change  screen  color 

1114 

@5,37  SAY  cage 

&&  Display  cage 

1115 

SELECT  C 

Use  alternate  work  area 

1116 

USE  cd.cf  INDEX  cdcf_n_c 

&&  Activate  CDCF.DBF 

1117 

SEEK  mnsn+pr_temD->cage 

Look  for  cage 

1118 

STORE  .T.  TO  mflag 

1119 

DO  WHILE  .NOT.  EOF()  .AND.  (nsn  :  mnsn 

.AND.  cage  =  or_temo->cage) 

1120 

@8,14  SAY  disc_code 

1121 

@  $,$+1  SAY  LEFT(disc,60) 

1122 

@  $+1,14  SAY  cause_code 

1123 

@  $,$+1  SAY  LEFT(cause,60) 

1124 

@  $+1,14  SAY  disp_code 

’125 

@  $,$+1  SAY  LEFT(disp,60) 

1126 

@  $+1,14  SAY  corr_code 

1127 

@  $,$+1  SAY  LEFT(corr,60) 

1128 

@  23,0  SAY  '  ' 

&&  Position  curser 
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1129 

WAIT 

&&  Wait  on  key  press 

1130 

SKIP 

&&  Find  next  occurrence 

1131 

ENDDO 

1132 

END  IF 

1133 

1134 

RETURN 

&&  Return  to  calling  program 

1135 

1136 

1137 

t 

1138 

***  AWARD  SCREEN  *****int***********t********************t**** 

1139 

* 

* 

1140 

*  After  the  buyer  makes  a  decision  as  to  who  will  receive  the  ♦ 

1141 

*  contract,  this  screen  will  show  the  information  needed  to  ♦ 

1142 

*  complete  the  resulting  paperwork. 

* 

1143 

* 

* 

1144 

1145 

^f^^^^*i^4t***^^^****************i^*■l^i^*****■^^**************************** 

1146 

1147 

PROCEDURE  AwardScr 

&&  Labels  this  block  of  code 

1148 

1149 

@  23,0  CLEAR 

&&  Clear  the  screen 

1150 

SET  COLOR  TO  G/B 

&&  Set  normal  screen  colors 

1151 

1152 

I  23,25  SAY  'Display  Details  For:’ 

Display  user  instructions 

1153 

@  24,10  SAY  'Press  (SPACE  BAR)  For  Next  Choice 

-  Any  Other  Key  To  Accept’ 

1154 

1155 

*  >>>  DISPLAY  CAGE  CODES  <<< 

1156 

1157 

SELECT  Dr_temD 

&&  Activate  PRJEMP.DBF 

1158 

GOTO  TOP 

&&  Set  pointer  to  first  record 

1159 

SET  COLOR  TO  BG/B 

&&  Change  display  color 

1160 

STORE  '  ’  TO  mchoice 

Reset  user's  selection 

1161 

1162 

DO  WHILE  mchoice  :: 

&&  Display  cage  codes 

1163 

IF  .NOT.  EOF() 

1164 

@  23,47  SAY  cage  + 

1165 

ELSE 

&&  IF  End  Of  File 

1166 

@  23,47  SAY  'No  One’ 

&&  Display  'No  One’ 

1167 

END  IF 

1168 

1169 

*  >>>  GET  USER'S  SELECTION  <<< 

1170 

1171 

WAIT  ' '  TO  mchoice 

&&  Get  user's  choice 

1172 

IF  mchoice  = 

&&  If  space  bar 

1173 

IF  .NOT.  EOF() 

1174 

SKIP 

&&  Move  pointer  to  next  record 

1175 

ELSE 

1176 

GOTO  TOP 

44  Position  pointer  at  record  one 
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1177  ENDIF 

1178  ENDIF 

1179  ENDDO 

1180 
1181 

1132  *  >>>  DISPLAY  USER'S  CHOICE  <<< 

1183 

1184  IF  EOF() 

1185  STORE  mreturn  TO  mchoice 


1185 

n 

1186 

ELSE 

1187 

1188 

CLEAR 

1189 

SET  COLOR  TO  G/B 

1190 

1191 

1192 

*  >>>  DRAW  GRIDS  <<< 

1193 

1194 

1195 

@ 

2,0  TO  21,79  DOUBLE 

1196 

8,1  TO  8,78  DOUBLE 

r97 

§ 

16,1  TO  16,78  DOUBLE 

1198 

18,1  TO  18,78 

1199 

@ 

3,39  TO  7,39  • 

1200 

17,13  TO  20,13 

1201 

@ 

17,24  TO  20,24 

1202 

@ 

17,35  TO  20,35 

1203 

17,46  TO  20,46 

1204 

@ 

17,57  TO  20,57 

1205 

@ 

17,68  TO  20,68 

1206 

1207 

8,0  SAY  CHR{204) 

1207 

ersect 

;ions 

1208 

9 

16,0  SAY  CHR(204) 

1209 

9 

18,0  SAY  CHR(199) 

1210 

1211 

9 

8,79  SAY  CHR(185) 

1212 

9 

16,79  SAY  CHR(185) 

1213 

9 

18,79  SAY  CHR{182) 

1214 

1215 

9 

2,39  SAY  CHR(209) 

1216 

9 

8,39  SAY  CHR(207) 

1217 

1218 

9 

16,13  SAY  CHR{209) 

1219 

9 

16,24  SAY  CHR(209) 

1220 

9 

16,35  SAY  CHR{2Q9) 

1221 

9 

16,46  SAY  CHR(209) 

1222 

9 

16,57  SAY  CHR(209) 

&&  End  of  display  cage  codes 


&&  Prepare  to  return  to  last  scree 


ii  Clear  screen 
iS,  Set  color  to  normal 


&&  Draw  boxes/1 ines 


Place  soecial  characters  at  int 
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1223  @  16,68  SAY  CHR(209) 

1224 

1225  @  21,13  SAY  CHR(207) 

1226  @  21,24  SAY  CHR{207) 

1227  @  21,35  SAY  CHR( 207) 

1228  @  21,46  SAY  CHR(207) 

1229  @  21,57  SAY  CHR(207) 

1230  @  21,68  SAY  CHR( 207) 

1231 

1232  @  18,13  SAY  CHR(197) 

1233  @  18,24  SAY  CHR(197) 

1234  @  18,35  SAY  CHR(197) 

1235  @  18,46  SAY  CHR{  197) 

1236  @  18,57  SAY  CHR(197) 

1237  @  18,68  SAY  CHR( 197) 

1238 

1239 

1240  *  >>>  FILL  IN  CONSTANTS  <<< 

1241 

1242  @  0,0  SAY  'Award  Information  For:' 

1243 

1244  @  3,2  SAY  'Vendor: ' 

1245  @  3,41  SAY  'Remit  To:' 

1246  @-ia.-2  SAY  'Cage:' 

1247  @  10,31  SAY  'State  Code:' 

1248  @  10,64  SAY  'Source  Type:’ 

1249  @  12,2  SAY  'Discount:  %  In  Days’ 

1250  @  12,59  SAY  'Variance:  +  S!  -  5S' 

1251  @  14,2  SAY  'Delivery  Time:  Days' 

1252  @  14,38  SAY  'FOB:' 

1253  §  14,66  SAY  'RFCC  Code:' 

1254  @  19,2  SAY  'Unit  Price' 

1255  @  20,2  SAY  'Ext.  Price' 

1256 

1257  §  23,25  SAY  'Press  <P>  For  Previous  Screen' 

1258  §  24,26  SAY  'Any  Other  Key  When  Finished' 

1259 

1260  SET  COLOR  TO  W/B 

1261  §  0,23  SAY  mnsn 

1262 

1263 

1264  *  >>>  FILL  IN  VENDOR  SPECIFIC  DATA  (<< 

1265 

1266  SELECT  VENDOR 

1267 

1266  @  4,4  SAY  addressi 

1269  @  5.4  SAY  address2 

1270  @  6,4  SAY  address3 


&&  Print  static  text 


Change  screen  colors 
&&  Print  NSN 


&&  Activate  VENDOR. DBF 

S&  Relation  was  set  from 
&&  PR  TEMP 
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1271 

@  7,4  SAY  address4 

1272 

1273 

@  4,43  SAY  remiti 

&&  Print  billing  address 

1274 

@  5,43  SAY  re(nit2 

1275 

@  6,43  SAY  remits 

1276 

§  7,43  SAY  remit4 

1277 

1278 

@  10,8  SAY  cage 

&&  Print  other  vendor  information 

1279 

@  10,43  SAY  state 

1280 

@  10,77  SAY  size_code 

1281 

@  12,12  SAY  disc  PICTURE  ‘9.999’ 

1282 

@  12,22  SAY  days 

1283 

@  12,70  SAY  qty_var_p 

1284 

@  12,75  SAY  qty_var_m 

1285 

@  14,17  SAY  del ivery 

1286 

§  14,43  SAY  fob 

1287 

@  14,77  SAY  rfcc 

1288 

1289 

1290 

*  >>>  FILL  IN  PRICING  DATA  <<< 

1291 

1292 

SET  COLOR  TO  G/B 

Set  standard  colors 

1293 

1294 

@  17,16  SAY  morderl  PICTURE.  '@Z  99.999’ 

Print  order  quantities 

1295 

@  17,27  SAY  morder2  PICTURE  ’@Z  99,999’ 

1296 

@  17,38  SAY  morder3  PICTURE  ’@Z  99,999’ 

1297 

@  17,49  SAY  morder4  PICTURE  '@Z  99,999’ 

1298 

§  17,60  SAY  morder5  PICTURE  ’@Z  99,999’ 

1299 

@  17,71  SAY  morderS  PICTURE  ’@Z  99,999’ 

1300 

1301 

♦  >>)  SEARCH  FOR  SELECTED  VENDOR  IN  PRICING  MATRIX  <<< 

1302 

1303 

STORE  1  TO  mcounter 

&&  Initial ize  counter 

1304 

STORE  mcagel  TO  mcage 

&&  Store  first  cage  in  matr'x 

1305 

1 F  TYPE( ’mcage' )  =  'N' 

!ti  If  it  IS  all  numeric. 

1306 

STORE  STR(mcage,5)  TO  mcage 

&&  Convert  to  string 

1307 

END  IF 

1308 

1309 

DO  WHILE  cage  <>  mcage 

&&  Search  for  orooer  cage  in  matn 

1309 

1310 

STORE  mcounter+l  TO  mcounter 

Si  Advance  counter  by  1 

1311 

STORE  ’ MCAGE ’+LTRIM(STR (mcounter))  TO  mcage 

1312 

STORE  &mcage  TO  mcage 

SS  Stor'i  next  cage  in  matrix 

1313 

IF  TYPE( ’mcage' )  =  ’N’ 

5S  If  cage  is  numeric. 

1314 

STORE  STR(mcage,5)  TO  mcage 

SS  Lcnvert  to  string 

1315 

END  IF 

1316 

ENDDO 

SS  End  searching  for  cage 

1317 
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1318 

SET  COLOR  TO  W/B 

&&  Enhance  screen  colors 

1319 

STORE  15  TO  mcolumn 

Initialize  screen  pointer 

1320 

STORE  1  TO  mcol 

&&  Initialize  pointer 

1321 

1322 

DO  WHILE  mcol  <  7 

ii  Print  the  prices 

1323 

STORE  ’HEXT_'+LTRlM(STR(mcounter))+’_'+LTRIM(STR(mcol))  TO  mprice 

1324 

STORE  ’MORDER'+LTRIM(STR(mcol))  TO  morder 

1325 

STORE  &mpr ice/&morder  TO  mnet_price 

1326 

@  19,mcoIumn-1  SAY  mnet_price  PICTURE 

'@Z  9,999.9999' 

1327 

@  20, mcolumn  SAY  &mprice  PICTURE  '@Z  99,999.99’ 

1328 

1329 

STORE  mcoUl  TO  mcol 

Advance  the  counters 

1330 

STORE  mcolumn+11  TO  mcolumn 

1331 

ENDOO 

1332 

1333 

SET  COLOR  TO  G/B 

&&  Return  color  to  normal 

1334 

END  IF 

1335 

1336 

1337 

*  >>>  GET  USER  RESPONSE  <<< 

1338 

1339 

9  23,0  SAY  ■  ' 

&&  Position  curser 

1340 

WAIT  '  '  TO  mchoice 

&&  Get  user's  input 

1341 

IF  UPPER(mchoice)  :  'P' 

&&  User  pressed  ' 

1342 

STORE  mreturn  TO  mchoice 

&&  Prepare  to  return  to  prior  sere 

1342 

en 

1343 

ELSE 

1344 

STORE  'Q'  TO  mchoice 

&&  Prepare  to  quit 

1345 

END  IF 

1346 

1347 

RETURN 

&&  Return  control  to  calling  progr 

1347 

am 

1348 

1349 

1350 

1351 

RETURN  TO  OPENING  SCREEN  *$*****t*t************t****t***i( 

1352 

* 

* 

1353 

*  if  the  users  presses  <ESC><ESC>  while  entering  the  NSN,  * 

1354 

*  control  is  directed  to  this  program  code. 

The  user  will  be  * 

1355 

*  returned  to  the  program  information  screen 

* 

1356 

* 

* 

1357 

1358 

1359 

PROCEDURE  RTURN 

SS  Label  this  block  of  code 

1360 

1361 

STORE  'Q'  TO  mchoice 

4&  Prepare  to  quit  program 

1362 

RETURN  TO  MASTER 

&&  Return  to  master  program 

1363 
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tt**t******t*t**t*****t***************t**t************************t** 

Program:  SELCTVEN.PRG 


7/30/91 

11:42 


System:  Automated  Vendor  Selection  Assistant 
Author:  Capt  Daniel  E.  Hagmaier 
Copyright  (c)  1991,  United  States  Air  Force 

Called  by:  AVSA.PRG 


Uses 


Indexes 


PR_TEMP.DBF 
NSN.OBF 
PR  ICE. DBF 
DCRL.DBF 
VENDOR. DBF 

N_NSN.NDX 
P_C_CODE.NDX 
DCR_CAGE.NDX 
V  C  MIL.NDX 


Documented:  7/30/91 


11:36 


SNAP!  version  1.73 


*$*««***««$«***«***«**********:*******************«******************* 


* 

* 

* 

* 

* 

« 


SELECT  QUALIFIED  VENDORS  ******t*****************t******* 

* 

This  orocedure  file  selects  the  qualified  vendors  bidding 
on  the  item  identified  in  the  Screens  Procedure.  Memory 
variables  mNSN,  mQUANTITY,  and  mSETASiDE  from  the  incut 
screen,  are  used  in  the  selection  process. 


* 
* 
* 
* 
* 

tt*t**t%*tt******t*t*tt**-******t*******t**tt***%************%%*** 


VENDOR  SELECTION  **************************************** 

* 

This  portion  of  the  code  creates  a  temporary  datafile,  * 
PR_TEMP.OBF.  In  it,  records  from  the  price  database  that  * 
contain  bidding  vendors,  will  be  copied.  * 


» 

* 

* 

* 

*  t 

t*tt***-$t*$****%*t**it$**t****tn*i*tt***tt**t****t*****tt****t** 


>  > ) 


.OAD  TEMPORARY 


<<< 


Page  1 
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49 

50 

51 

52 

53 

54 

55 

55 

56 

57 

58 

59 

60 
61 
62 
62 
63 

63 

64 

64 

65 

65 

66 
56 
67 

67 

68 
68 
69 

69 

70 

70 

71 

71 

72 

72 

73 

74 

75 

76 

77 

78 

79 

80 
81 
82 

83 

84 


SELECT  A 
USE  pr.temp 
SELECT  a 

USE  nsn  INDEX  n_nsn 
SELECT  C 


&&  Select  primary  work  area 
&&  Activate  PRJEMP.dbf 
Select  alternate  work  area 
&&  Activate  NSN.dbf 
&&  Select  alternate  work  area 


&&  Activate  PRICE. dbf  w/  CAGE  &  PR 


iSi  Select  alternate  work  area 
4&  Tie  the  two  db  files  together 
44  Locate  NSN 


USE  price  INDEX  p_c_code 
_CODE 
SELECT  a 

SET  RELATION  TO  cage+pr ice_code  INTO  price 
SEEK  mnsn 
DO  WHILE  nsn  =  mnsn 

SELECT  A  44  Select  primary  work  area 

APPEND  BLANK  44  Generate  blank  record 

REPLACE  cage  WITH  nsn->cage,  price_code  WITH  nsn->price_code,.mi l_spec  WITH  nsn 
->mi l_spec 

REPLACE  qminl  WITH  price->qmin1 ,  qmaxi  WITH  price->qmaxl ,  pricel  WITH  Drice->p 
ricel 

REPLACE  qmin2  WITH  orice->qmin2,  qmax2  WITH  Drice->qmax2,  Drice2  WITH  price->o 
rice2 

REPLACE  qmin3  WITH  price->qmin3.  qmax3  WITH  orice->qmax3,  price3  WITH  orics'/p 
rice3 

REPLACE  qmin4  WITH  price->qmin4,  qmax4  WITH  price->qmax4,  price4  WITH  pnce->D 
rice4 

REPLACE  qmin5  WITH  crice->qmin5,  qmax5  WITH  price->qmax5,  crice'5  WITH  cr:ce'>o 
nce5 

REPLACE  qmin6  WITH  Drice->omin6,  qmax6  WITH  price->qmax6,  price6  WITH  Drice->o 
r  ice6 

REPLACE  qmin7  WITH  price->qmin7,  qmax7  WITH  once->omax7,  price7  WITH  price->D 
rice7 

REPLACE  qmin8  WITH  pr ice-)qmin8,  qmax8  WITH  price->qmax8,  price8  WITH  cr'ce->c 
riceS 

REPLACE  qm’n9  WITH  Drice-)qmin9,  qmax9  WITH  price->qmax9,  price9  WITH  orice->D 
rice9 

REPLACE  qminlO  WITH  Dnce->qmin10,  qmaxlO  WITH  orice->qmaxl0,  pncelO  WITH  cr- 
ce->price10 

SELECT  a  44  Select  alternate  work  area 

SKIP  44  Move  pointer  to  next  record 

ENDDO  44  End  of  load  PR  TEMP. dbf 


***  REMOVE  UNQUALIFIED  VENDORS  ******t*t****tt************* 
*  * 

*  Of  the  vendors  in  the  temoorary  database,  vendors  which  * 

*  have  been  de-barred  are  ’Deleted'.  Also,  if  the  procure-  * 

*  ment  is  set  aside  for  small  business,  the  large  vendors  * 

*  will  be  'Deleted'.  The  remaining  vendors  will  latter  be  * 

*  checked  for  other  problems,  or  excellence.  * 
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85 

* 

* 

86 

87 

88 

89 

90 

Q  1 

*  >>>  IDENTIFY  DE-3ARRED  VENDOR(S)  <<< 

y  1 

92 

SELECT  C 

&&  Establish  alternate  work  area 

93 

USE  dcrl  INDEX  dcr_cage 

&&  Open  DCRL. DBF  file 

94 

95 

SELECT  Dr_temp 

Activate  PRJEMP.DBF 

96 

GO  TOP 

i&  Set  pointer  to  the  first  record 

97 

DO  WHILE  .NOT.  EOF() 

&&  Check  entire  file 

98 

SELECT  dcrl 

&&  Activate  DCRL. DBF 

99 

LOCATE  FOR  (pr_temo->cage  =  cage) 

&4  Look  for  first  cage  in  PR_TEY1P. 

99 

DBF 

100 

IF  FOUNDO 

101 

IF  categoryl  =  ‘A’  .OR.  category2  ^  'A' 

.OR.  category3  =  'A' ; 

102 

.OR.  category4  :  'A'  .OR.  category5 

:  ’A’  .OR.  categoryB  :  'A' 

103 

SELECT  pr_tefflc 

104 

DELETE 

&&  Marks  current  rec  for  deletion 

105 

ENOIF 

106 

END  IF 

107 

SELECT  pr_temD 

8i8.  Activate  PRJEMP.DBF 

100 

SKIP 

ii  Advance  to  next  record 

109 

ENDDO 

&&  Repeat  until  end  of  3R_TEMP.D3F 

110 

1  1  1 

:  1  1 

112 

113 

*  ))}  SET-A-3IDE  <<< 

114 

115 

IF  msetaside  =  "Y” 

&S  If  PR  is  for  small  business 

116 

117 


118 

119 

120 

♦)>>  LINK  PR_CAGE.DBF  WITH  VENDOR. DBF  ( 

<< 

SELECT  B 

&&  Select  alternate  work  area 

121 

USE  vendor  INDEX  v_c_mil 

hi  Open  VENDOR. DBF  for  use 

122 

SELECT  A 

&&  Select  cr’mary  work  area 

123 

124 

125 

SET  RELATION  I'D  cage+mi  l_SDec  INTO  vendor 

Link  datafiles  together 

126  * 
127 

)))  REMOVE  VENDORS  COOED  AS  LARGE  <<< 

'28 

SELEC’  Dr_temo 

&&  Activate  PR_TEMP.OBF 

129 

GO  TOP 

&&  Set  pointer  to  first  revord 

'30 

DO  WHILE  .NOT.  EOF() 

&i  Check  entire  file 

131 

IF  vendor->si2e_code  :  'A' 

&&  'A'  eauals  large  vendor 
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132 

132 

133 

134 

135 

136 

137 

138 

139 
14C 

141 

142 

143 

144 

145 

146 

147 

148 

149 

150 

151 

152 
'53 
154 

154 

155 

156 
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DELETE  &S  Mark  current  record  for  deletio 

n 

END  IF 

SKIP  &&  Move  pointer  to  next  record 

ENODO  &&  Repeat  until  end  of  file 


♦  ■)>>  REMOVE  LINK  WITH  VENDOR. DBF  <<< 

SET  RELATION  TO  &&  Removes  relation 


ENDIF 


&&  End  of  Set-A-Side  coding 


♦>>>  REMOVE  DELETED  FILES  (<< 


SELECT  Dr_temo 

Insure 

PRJEMP.DBF  IS  active 

PACK 

&&  Remove 

any  deleted  records 

RETURN 

Return 

control  to  calling  orogr 

a.in 

*;  EOF:  SELCTVEN.PRG 
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System:  Automated  Vendor  Se’ection  Ass:stant 
Author:  Capt  Daniel  £.  Hagmaier 
Cross-Reference  Report 
Date:  7/3C/9’ 

Time:  "!:33 


AVSA.°RG 


3CRFEMS.ORG 


SE.C'VEN.ORG 


A 

•♦u 

41 

43 

44 

45 

46 

A  7 

48 

49 

52 

o3 

64 

65 

66 

(•"T 

0  1 

68 

73 

74 

79 

30 

81 

82 

33 

84 

85 

86 

88 

89 

90 

9 ' 

92 

93 

105 

'27 

133 

’85 

136 

19’ 

193 

223 

226 

234 

236 

238 

252 

254 

255 

256 

251' 

258 

259 

260 

50 

5’ 

64 

75 

78 

S3 

108 

'09 
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QUANTITY 

SCREENS. PRG 


96 


Q_CAGE 

PREPVEN.PRG 


"8 


SCREENS. PRG  186  304  456  508  58'  586  596  600 
792  809 


RB 


AVSA.PRG 
SCREENS. PRG 


42 

470  510  794 


READ 

SCREENS. PRG 


118  177  222  240  262 


RECCOUNT 

AVSA.PRG 


'91 


RE  INDEX 

PREPVEN.PRG 


Z44 


RELATION 

SCREENS. PRG 

SELCTVEN.PRG 

PREPVEN.PRG 


159 

57  123  14’ 


3CM  ' 


SCREENS. PRG  1273 


RE’^'1'2 

SCREENS. PRG 


'274 


606  512 


B-27 


REMIT3 

SCREENS. PRG  :275 

REMIT4 

SCREENS. PRG  ’276 

REPLACE 


SELCTVEN.RRG 

62 

63 

64 

65 

66 

67 

68 

69 

72 

PREPVEN.PRG 

49 

68 

86 

165 

169 

173 

174 

■73 

182 

194 

195 

206 

207 

REQUIRED. 

SCREENS. PRG  36 

RESTRICT! 

SCREENS. PRG  1034 

PREPVEN.PRG  47 

RESTRICT2 

SCREENS. PRG  1035 

3REPVEN.PRG  47 

RESTRICT3 

SCREENS. PRG  1036 

PREPVEN.PRG  47 

RESTRICT4 

SCREENS. PRG  1037 

3REPVEN.PRG  48 

RESTRICTS 

SCREENS  PRG  1038 

PREPVEN.PRG  48 

RE’URN 

SCREENS.  PRG 

SE.C*VEN,3RG 
PREPVEN.PRG 

RFCC 

SCREENS. PRG  ’287 

R'GH’’- 

SCREENS. =RG  806 

R’URN 

SCREENS  PRG  "S’  1359 

S 

SCREENS. PPG  87 


64  123  226  268  286  320  637  895  913  931 
1048  '134  1347  1362 
*54 
384 


9-28 


234 


SAFETY 
AySA,3RG 

SCOREBOARD 

AVSA.RRG  47  258 

SCREENS 

AVSA.PRG  4S 

SEEK 


SCREENS. PRG 

178 

993 

^  7 

SELCTVEN.PRG 

58 

PREPVEN.PRG 

45 

66 

84 

SELCTSCR 

AVSA.PRG 

188 

SCREENS, PRG 

279 

SELC’VEN 

AVSA.PRG 

■39 

SELECT 

SCREENS. PRG 

154 

'56 

158 

1033 

1045 

1070 

SE.C’VEN.PRG 

50 

52 

54 

'C7 

'20 

i22 

PREPVEN.PRG 

41 

44 

52 

88 

♦  c 

:  j  w 

107 

3’1 

372 

SELECT-ION 

SCREENS. PRG 

35 

SELECTS 

SCREENS. -^RG 

ai” 

SlZE_CODE 

SCREENS. °RG 

33' 

'290 

SELCTVEN.PRG 

131 

SK  ^ 

SCREENS. PRG 

''30 

"74 

SELC'VEN.3RG 

74 

'08 

'34 

PREPVEN.PRG 

53 

7  * 

39 

SPACE 

AVSA.PRG  ’9 

S’A” 

SCREENS,  =>“G  ':'9 


500 

734 

953 

988 

990 

992 

1001 

115 

1157 

1266 

56 

GO 

73 

92 

95 

98 

'33 

’28 

151 

59 

62 

65 

70 

77 

30 

83 

1  1  r 

I  1  U 

163 

2’3 

240 

242 

263 

272 

2:4  280  282  324  356  378 


3-29 


STATUS 

AVSA.PRG 


AVSA.PRG 
SCREENS. PRQ 

PREPVEN.PRG 

SUBSTR 


TALK 

AVSA.ORG 


SCREENS. PRG 


TITLE 


'■'.ESCR 

AVSA.PRG 


PREPVEN.PRG  42 

TYPE 

SCREENS. PRG  1305 

U! 

SCREENS. PRG  220 

UNIT  PRICE 


UPPER 

AVSA.PRG 


JP_LIMIT 

SCREENS. PR^  585 

PREPVEN.PRG  265 


48 

259 

:oo 

107 

116 

116 

521 

521 

533 

562 

585 

610 

311 

1314 

1323 

1323 

1324 

128 

136 

158 

166 

167 

211 

193 

194 

195 

198 

199 

200 

49 

260 

83 

85 

87 

89 

94 

96 

192 

197 

1005 

1  J  1  u 

1015 

1020 

1025 

1030 

64 

44 

955 

961 

1072 

1078 

1158 

1176 

96 

129 

42 

63 

81 

112 

245 

313 

1305 

1313 

220 

168 

195 

202 

207 

251 

255 

199 

201 

204 

207 

209 

211 

624 

629 

890 

1341 

8-30 


USE 


AVSA.PRG  235  237 


SCREENS. PRG 

155 

157 

989 

991 

1046 

1116 

SELCTVEN.PRG 

51 

53 

55 

93 

121 

PREPVEN.PRG 

60 

78 

106 

108 

241 

273 

312 

VAL 

SCREENS. PRG 

193 

194 

195 

198 

199 

200 

806 

VENDOR 

SCREENS. PRG 

85 

87 

157 

159 

220 

800 

801 

802 

804 

805 

850 

851 

1266 

SELCIVEN.PRG 

121 

123 

131 

PREPVEN.PRG 

106 

111 

137 

188 

189 

189 

191 

194 

195 

201 

202  265 

VENORSCR 

AVSA.PRG  208 

SCREENS. PRG  648 

V_C_MIL 

SCREENS. PRG  !57 

SELCTVEN.PRG  121 

PREPVEN.PRG  106 

W 

SCREENS. PRG  1113  1260  1318  '  ■ 

WAIT 

SCREENS. PRG  62  316  625  630  891  969  1042  1086  1129  117' 

1340 

WHILE 

AVSA.PRG  66  99  106  113  115  199 

SCREENS. PRG  174  196  237  260  501  520  624  629  788  890 

959  1076  1119  1162  1309  1322 
SELCTVEN.PRG  59  97  130 

3REPVEN.PRG  43  64  82  126  134  159  191  279  326  344 

374 

WHC 

SCREENS. PRG  87 

WISH 

SCREENS. PRG  107 


B-31 


WITH 


SELCTVEN.PRG 

62 

62 

62 

65 

65 

66 

68 

69 

69 

72 

72 

72 

PREPVEN.PRG 

49 

68 

86 

182 

194 

195 

Y 

SCREENS. PRG 

107 

259 

YEAR 

AVSA.PRG 

132 

YOU 

SCREENS. PRG 

94 

107 

ZAP 

AVSA.PRG 

236 

238 

63 

63 

63 

64 

64 

64 

65 

66 

66 

67 

67 

67 

68 

68 

69 

70 

70 

70 

71 

71 

71 

165 

206 

168 

207 

173 

174 

178 

179 

181 
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Appendix  C:  Data  Base  Structure 


System:  Automated  Vendor  Selection  Assistant 

Author:  Caot  Darnel  £.  Hagmaier 

Database  Structure  Summary 

Date:  7/30/91 

Time:  11:37 


Structure  for  database  :  pr_TEMP.DB^ 
\umber  of  data  records  :  0 

Date  of  last  uodate  :  7/21/9’ 


lid 

"’eld  name 

Tyoe 

Width 

Dec 

♦ 

CAGE 

Character 

5 

2 

?RICE_CODE 

Character 

7 

3 

M;L_SPEC 

Character 

5 

GMI^Jl 

Mumeric 

5 

5 

QMAXl 

Numeric 

5 

S 

3R:CE1 

Numeric 

10 

4 

GMIN2 

Numeric 

5 

3 

QMAX2 

Numeric 

5 

3 

PRICE2 

Num.er  1C 

<  A 

<  J 

4 

’0 

QM'N3 

Numeric 

5 

*  " 

QMAX3 

Numeric 

5 

L 

PR1GE3 

Numer  ’  c 

'0 

4 

*2 

QMIN4 

Numeric 

5 

^4 

QMAX4 

Numeric 

5 

■5 

PR!CE4 

Numer'C 

10 

% 

^6 

QMIN5 

Numeric 

5 

4  "J 

QMAX5 

Numeric 

5 

’3 

PRICES 

Nw.me’"" 

4 

•9 

QMIN6 

Numer  i  c 

5 

20 

QMxe 

Numeric 

5 

r>i  4 

L  • 

PRICES 

Numeric 

10 

4 

0  0 

QM!N7 

Numeric 

5 

23 

QMAXl’ 

Numer  ■  c 

5 

24 

PR'CE7 

Numeric 

’0 

4 

GM!N8 

Numeric 

5 

26 

GMAX8 

Numeric 

5 

27 

PR'CE3 

Numer'C 

♦  A 

!  U 

4 

23 

GMINO 

Numeric 

C 

29 

QMAX9 

Numer’C 

5 

30 

PRICE9 

Numeric 

♦  A 
■J 

4 

3" 

Numer  ■  c 

5 

32 

Gf^AXlO 

Numeric 

5 

33 

PR'CE'; 

Numefc 

»  A 

1 

34 

PROS 

.og-cal 

• 

35 

CDCF 

Logica' 

• 

35 

GCAl'"'' 

Log-cal 

f 

1' 

■j  ' 

ij:3"ORv 

uogica’ 

* 

Used  by;  AVSA.PRG 
Used  bv:  3ELCTVEN.RRG 


Structure  ^or  database  ;  HOLD. DBF 
dumber  of  data  records  :  3 

Date  of  last  uodate  ;  7/21/91 


F:e!d  F^eld  "ame 

Tyoe 

W’dth 

Dec 

'  CAGE 

Character 

5 

2  CRD_QUANT 

Numeric 

5 

3  UNr_PR:CE 

Numeric 

’0 

4 

4  EX:_PR1CE 

Numer:c 

3 

0 

**  Tota’  ** 

29 

Used  by;  AVSA.PRG 
Used  by:  PREPVEN.PRG 


Structure  for  database  ;  MSN. DBF 
fiumber  of  data  records  ;  -15550 
Date  of  last  uodate  ;  7/20/91 
=ield  -ield  name  Tyoe  Width 

1  MSN  Character  16 

2  CAGE  Character  5 

3  MlLJPEC  Character  5 

4  PR!CE_C0DE  Character  7 

**  Tota’  **  34 


Dec 


Used  by;  SCREENS. PRG 
Used  oy;  SELCTVEN.PRG 


Structure  ^or  database  ;  DCRLCODE.DBF 
Nu.T0er  of  data  records  ;  "O 
Date  0^  'ast  uodate  6/12/9’ 

■•e'o  ''e’d  "aire  ^yoe  WTdth  Dec 

'  CODE  Character 

2  '"LE  Character  25 

**  "Ota’  **  27 

.sed  by;  SCREENS. ^RG 


structure  for  database  :  VENDOR. DBF 


Number  of  data  records  :  13 

Date  of  last  uodate  7/21/91 


Field 

Field  name 

Type 

Width 

1 

CAGE 

Character 

5 

2 

M1L_SPEC 

Character 

5 

3 

NAME 

Character 

30 

i 

SIZE_CODE 

Character 

1 

5 

DELIVERY 

Numeric 

3 

6 

QTY_VAR_P 

Numer i c 

2 

7 

qtyIvar_m 

Numeric 

2 

8 

FOB 

Character 

1 

9 

INSPECT 

Numeric 

6 

10 

DISC 

Numeric 

s 

11 

DAYS 

Numeric 

') 

u 

1  0 
i  L. 

NET 

Numeric 

2 

13 

LOTJIZE 

Numeric 

3 

'4 

m:n_crder 

Numeric 

6 

15 

o ! 

Character 

2 

16 

STATE 

Character 

2 

17 

RFCC 

Character 

'8 

ADORESSl 

Character 

35 

19 

A00RESS2 

Character 

35 

20 

ADDRESS3 

Character 

35 

2’ 

ADDRESS4 

Character 

35 

22 

REMIT1 

Character 

35 

23 

REM1T2 

Character 

35 

24 

SEMIT3 

Character 

35 

25 

REMIT4 

Character 

35 

**  ’otal  ** 

359 

Used  by:  SCREENS. 

PRG 

Used  b) 

:  SELCTVEN 

.PRG 

Used  b\ 

:  PREPVEN. 

DRG 

structure  for  database  :  DCRL.OBF 
Mumber  of  data  records  ;  3*8 
Date  of  'ast  uodate  ;  7/i9/91 


7d 

F:eld  name 

Type 

Width 

’ 

CAGE 

Character 

5 

2 

NAME1 

Character 

35 

3 

NAME2 

Character 

35 

4 

NAME3 

Character 

35 

5 

NAME4 

Character 

35 

G 

ADDED 

Character 

8 

7 

CHANGED 

Character 

8 

8 

DEL_'ND 

Character 

7 

9 

CA’EGORY' 

Character 

'5 

IQ 

DATE!  AIEI 

Character 

8 

1  1 

CATEGORY2 

Character 

15 

:2 

da:e2 

Character 

3 

13 

CATEGORY3 

Character 

15 

14 

DATE3 

Character 

3 

15 

CATEGCRY4 

Character 

15 

’6 

DATE4 

Character 

8 

17 

ca:egory5 

Character 

'5 

'8 

u  A  1  w  0 

Character 

8 

19 

CATEGORYG 

Character 

15 

20 

DATES 

Character 

8 

21 

RESTRICT! 

Character 

50 

22 

RESTRICT2 

Character 

50 

23 

RESTRICTS 

Character 

50 

24 

RESTRICT4 

Character 

50 

25 

RESTRICTS 

Character 

50 

’otal  « 

557 

Used  by:  SCREENS. PRG 
Used  by:  SELC’VEN.PRG 


Structure  for  database  :  MODEL. DBF 

Number 

of  data  records  : 

* 

Date  0 

f  ’ast  -cdate  7/ 

2/91 

Fie’d 

F-eld  name  I’yoe 

Width 

Dec 

uCW  Numeric 

A 

'jo_.  Numeric 

6 

3 

w:S*CRY‘  Nume'-'C 

4 

m;S'CRv2  Nume-;: 

7 

L 

c 

A_'  Numeric 

■j 

**  'ot 

al  ** 

7  ♦ 

L  ■ 

Used  by:  SCREENS. PPG 
^3sd  ty ^^E^VEN.^^G 


C-4 


structure  for  database  :  PR  ICE. DBF 


Number  of  data  records  ;  405 

Date  of  last  uodate  :  7/20/91 


F:eld 

Field  rame 

■^yce 

Width 

Dec 

1 

1 

CAGE 

Character 

5 

2 

PR1CE_C0DE 

Character 

7 

3 

QMIN1 

Numeric 

5 

4 

QMAXl 

Numeric 

5 

5 

PRICE! 

Numeric 

10 

4 

6 

QMIN2 

Numeric 

5 

7 

QMAX2 

Numeric 

5 

8 

PRICE2 

Numeric 

^  r\ 

\  J 

4 

9 

QM1N3 

Numeric 

5 

10 

QMAX3 

Numer i c 

5 

PRICE3 

Numeric 

♦  r\ 

*♦ 

1  0 

1  L 

QM1N4 

Numeric 

5 

■3 

QMAX4 

Numeric 

5 

14 

PR1CE4 

Numeric 

’0 

4 

15 

GMIN5 

Numeric 

5 

16 

QMAX5 

Numer ■ c 

5 

'7 

PRICE5 

Numeric 

1  A 
■  J 

4 

13 

QMIN6 

Numeric 

5 

19 

QMAX6 

Numeric 

5 

20 

PRICE6 

Numer 'c 

10 

4 

21 

QMIN7 

Numeric 

5 

22 

QMAX7 

Numeric 

5 

23 

PRICE7 

Numeric 

10 

4 

24 

CM  INS 

Numeric 

5 

25 

QMAX8 

Numeric 

5 

26 

PRICES 

Numeric 

10 

4 

27 

QM1N9 

Numeric 

5 

28 

QMAX9 

Numeric 

5 

29 

PRICES 

Numeric 

10 

t 

»* 

30 

QMINIO 

Numeric 

5 

31 

QMAX10 

Numeric 

5 

32 

3RICE10 

Numeric 

’0 

4 

**  Total  ** 

213 

Lised  by:  SELCTVEN, 

PRG 

C-5 


Structure  for  database  ;  CDCF 

.DBF 

Number 

of  data  records  :  9458 

Date  of  last  update  :  7/  9/91 

Field 

Field  name 

Type 

Width 

; 

NSN 

Character 

16 

2 

CAGE 

Character 

5 

3 

d;sc_code 

Character 

2 

4 

DISC 

Character 

56 

5 

CAUSE.CODE 

uharacter 

6 

CAUSE 

Character 

56 

7 

d:sp_code 

Character 

L 

8 

d:s? 

Character 

56 

9 

C0RR_C0DE 

Character 

2 

10 

CORR 

Character 

56 

**  Total  ♦* 

254 

Used  by:  SCREENS. ?RG 
Used  by;  PREPVEN.PRG 


Structure  for  database 
Number  of  data  -ecords 


Date  of  last  uodate 
- -e’d  F:eld  "ame 
’  CAGE 
:  VENDOR 
3  FSC 
**  ’otal  ** 


QUALITY.OB'' 
■  24 
7/:9/91 
’■yoe  Width 

Character  5 

Character  25 

Numeric  4 

35 


Dec 


Used  by:  PREPVEN.PRG 


ct-re 
( 


St 

Numbe’"  0 
Date  0* 

=  'eld  F 


‘s'-  database 
data  records 
’ast  uOdate 
leld  name  ’’voe 


NSN 

DATE 

CAGE 

PRICE 

GUAN" 


Character 

Character 

Character 

Numeric 

Numeric 


ij:S’‘CR^.DS- 

^  f  7 

T/20/9- 
w-dtr 
IG 


«  "Ota’  ** 


5 

5 

6 
5 

38 


Dec 


Used  by:  PREPVEN.PRG 


C-6 


System;  Automated  Vendor  Selection  Assistant 

Author:  Cact  Daniel  £.  Hagmaier 

Data  Dictionary 

Date:  7/30/91 

Time:  11:38 


Field  Name 

Tyoe 

Len 

Dec 

Database 

ADDED 

C 

3 

0 

DCRL.DBF 

ADDRESS  1 

C 

35 

0 

VENDOR. DBF 

ADDRESS2 

C 

35 

0 

VENDOR. DBF 

A0DRESS3 

c 

35 

0 

VENDOR. DBF 

ADDRESS4 

c 

35 

0 

VENDOR. DBF 

ALT 

N 

3 

0 

MODEL. DBF 

CAGE 

c 

5 

0 

?R_TEMP.DBF 
HOLD. DBF 
NSN.DBF 
VENDOR. DBF 
DCRL.DBF 
COCF. DBF 

PR  ICE. DBF 
QUALITY. DBF 
HI  STORY. DBF 

CATEGORY  1 

c 

15 

,0 

DCRL.DBF 

CATEGORY2 

c 

15 

0 

DCRL.DBF 

CATEGORY3 

c 

15 

0 

DCRL.DBF 

CATEG0RY4 

c 

‘5 

3 

DCRL.DBF 

CATEG0RY5 

c 

1  c 

A 

■J 

DCRL.DBF 

CATEGCRYG 

c 

■'5 

0 

DCRL.DBF 

CAUSE 

56 

Q 

CDCF.DBF 

CAUSE_CODE 

rh 

4. 

0 

CDCF.DBF 

COCF 

1 

[ 

0 

PRJEMP.DBF 

CHANGED 

r‘ 

8 

0 

DCRL.DBF 

CODE 

c 

n 

u 

OCRLCODE.DB^ 

CCRR 

c 

56 

0 

CDCF.DBF 

C0RR_C00E 

c 

2 

0 

CDCF.DBF 

DA’-E* 

c 

5 

0 

HISTORY. DBF 

DATEIATE’ 

c 

8 

0 

DCRL.DBF 

DA’E2 

c 

8 

0 

DCRL.DBF 

DA^E3 

c 

3 

n 

DCRL.DBF 

DATE4 

c 

3 

0 

DCRL.DBF 

DA'ES 

8 

n 

w 

DCRL.DBF 

DA’ES 

c 

8 

0 

DCRL.DBF 

DA'-S 

N 

0 

4. 

0 

VENDOR. DBF 

DELIVERY 

N 

3 

0 

VENDOR. DBF 

DEL_:nD 

C 

7 

n 

U 

DCRL.DBF 

DISC 

N 

5 

3 

VENDOR. DBF 

DISC 

r- 

56 

0 

CDCF.DBF 

D 1 SC_CCDE 

C 

0 

L 

0 

CDCF.DBF 

DISP 

C 

56 

0 

CDCF.OBF 

DISP_CODE 

C 

2 

0 

CDCF.DBF 

EXTJRICE 

N 

8 

2 

HOLD. DBF 

FOB 

C 

1 

1 

0 

VENDOR. DBF 

FSC 

N 

4 

0 

QUALITY. DBF 

HISTORY 

w 

1 

1 

0 

PRJEMP.DBF 

HI  STORY  I 

N 

2 

0 

MODEL. DBF 

HISTORY2 

N 

7 

2 

MODEL. DBF 

INSPECT 

N 

6 

2 

VENDOR. DBF 

LOTJ 1 ZE 

N 

3 

0 

VENDOR. DBF 

LOW 

N 

2 

0 

MODEL. DBF 

M!L_SPEC 

C 

5 

0 

PRJEMP.DBF 
NSN. DBF 
VENDOR. DBF 

H!N_ORDER 

N 

6 

2 

VENDOR. DBF 

NAME 

C 

30 

0 

VENDOR. DBF 

NAME  1 

C 

35 

0 

OCRL.DBF 

NAME  2 

35 

0 

DCRL.DBF 

NAHE3 

C 

35 

0 

OCRL.DBF 

NAMEA 

C 

35 

0 

DCRL.DBF 

NET 

N 

2 

0 

VENDOR. DBF 

NSN 

C 

•6 

0 

NSN. DBF 
CDCF.DBF 

HI  STORY. DBF 

ORD.QUANT 

N 

5 

0 

HOLD. DBF 

PRICE 

N 

6 

2 

HI  STORY. DBF 

PRICE1 

.  N 

TO 

4 

PR.TEMP.OBF 

pr'ce.dbf 

PRICEIC 

N 

10 

4 

PRJEMP.DSF 
PR  ICE. DBF 

PRICE2 

N 

10 

4 

PRJEMP.OBF 
PR  ICE. DBF 

or:CE3 

N 

*  n 
<  u 

4 

PR_TEMP.OBF 
PR  ICE. DBF 

PRICE4 

N 

10 

4 

PR_TEMP.DBF 
PR  ICE. DBF 

PRICES 

N 

10 

4 

PR_TEMP.DBF 
PR  ICE. DBF 

PRICES 

N 

10 

4 

PR_TEMP.DBF 
PR  ICE. DBF 

PRICE? 

N 

10 

4 

PR_TEMP.OBF 
PR  ICE. DBF 

PRICES 

N 

10 

4 

PRJEMP.DSF 
PR  ICE. DBF 

PRICES 

N 

10 

4 

PR_TEMP.DBF 
PR  ICE. DBF 

PR!CE_COO£ 

7 

0 

PR_TEMP.DBF 
NSN. DBF 

PR  ICE. DBF 

PROB 

L 

n 

u 

PR_TEMP.D8F 

QMAX1 

5 

0 

PRJEMP.DSF 
PR  ICE. DBF 

C-8 


QMAX10 

N 

5 

0 

PR_TEMP.D6F 
PRICE. DBF 

QMAX2 

N 

5 

0 

PR_TEMP,OBF 
PR  ICE. DBF 

QMAX3 

N 

5 

0 

PR_TEMP.OBF 
PR  ICE. DBF 

QMAX4 

N 

5 

0 

PR_TEMP.DBF 
PR  ICE. DBF 

QMAX5 

N 

5 

0 

PR_TEMP.DBF 
PR  ICE. DBF 

QMAX6 

N 

5 

0 

PR_TEMP.DBF 
PR  ICE. DBF 

QMAX7 

N 

5 

0 

PR_TEMP.D8F 
PR  ICE. DBF 

QMAX8 

N 

5 

n 

J 

PR_TEMP.DBF 
PRICE. DBF 

QMAX9 

N 

5 

0 

PR_TEMP.DBF 
PR  ICE. DBF 

Q,r:x: 

N 

5 

0 

PR_TEMP.OBF 
PRICE. DBF 

QMIN'O 

N 

5 

0 

PR_TEMP.DSF 
PR  ICE. DBF 

N 

5 

f\ 

PR_TE«P.OBF- 
PR  ICE. DBF 

QM1N3 

N 

5 

0 

PR_T£MP.06F 
PR  ICE. DBF 

QMIN'4 

N  . 

5 

u 

PR_TEMP.DBF 
PR  ICE. DBF 

QMIN5 

N 

5 

0 

PRJEMP.DBF 

prTce.dbf 

QMIN6 

N 

5 

PRJEMP.DBF 
PR  ICE. DBF 

qi^;n7 

N 

5 

0 

PRJEMP.DBF 
PRICE. DBF 

QMIN8 

N 

5 

0 

PRJEMP.DBF 
PRICE. DBF 

aMIN3 

N 

5 

0 

PRJEMP.DBF 

prTce.dbf 

G’'y_VAR_M 

N 

0 

<1 

0 

VENDOR. DBF 

gTY_VAR_P 

N 

2 

0 

VENDOR. DBF 

quality 

i_ 

1 

0 

PRJEMP.DBF 

QUANT ry 

N 

5 

0 

HI  STORY. DBF 

RE^l” 

C 

35 

0 

VENDOR. DBF 

REY!iT2 

C 

35 

0 

VENDOR. DBF 

REMIT3 

C 

35 

0 

VENDOR. DBF 

RE>’!’‘4 

C 

35 

0 

VENDOR. DBF 

RESTRICT' 

C 

50 

0 

DCRL.DBF 

RES*R:C’2 

C 

50 

0 

DCRL.D3F 

RESTRlcn 

c 

50 

0 

DCRL.DBF 

RESTR!C’4 

r\ 

50 

0 

DCRL.DBF 

RESTRICTS 

C 

50 

0 

DCRL.DBF 

RFCC 

c 

0 

VENDOR. DBF 
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SiZE.CODE 

C 

1 

1 

0 

VENDOR. DBF 

STA’E 

c 

2 

0 

VENDOR. DBF 

title 

c 

25 

DCRLCOOE.DBF 

Li  1 

c 

2 

f\ 

VENDOR. DBF 

UNIT_PR!CE 

N 

:o 

4 

HOLD. DBF 

lp_.imit 

N 

6 

0 

MODEL. DBF 

VENDOR 

C 

25 

0 

QUALITY. DBF 

Appendix  D:  0th er  Program  Documentation 

System:  Automated  Vendor  Se'ect'or  Ass  tart 
Auttor:  Cast  S3n:e’  E.  -agmaier 
- ^ 'e  -’St 
Date:  ^/30/9' 

^•me:  ■':39 


^■"ograms  arc  cscedutes: 
A\A^ZSC9--c:"oceaure 
AVSA.3RG 

Ay/ARDSCR--orocedLre 
^  C0CF3CR--:''ocedu’'e 
'JFC_SCr?--cr3cedure 
H ‘ ".SCR--Drocedure 
\'d"SC^--crcc3au.''3 
NCVEiJSCR--D''OceaLj'“e 
aoE^vEVj ,  PRG 
PR  iCESCR'-cocea^-e 
=RC3''SCR--:rocedure 
SCREENS. PRG 
3E.C’SCR--crocedure 
SElC’VEN.PPG 
” '  ’’-ESCR-'troceoure 
VEN0RSCR--O''o:ed-'‘e 

arocedu-e  ' es: 

SCREENS.  =-''G 


Databases: 

CCCF .  DB- 
DCRL .33" 
DCRlCCCE  .  DB" 
--  o'CR'^CSF 

“Cl:.d3- 
*^00  E-  ’'3'" 
NSN.DB- 
^R.CE.l-BF 
pq  -rvp  23F 

QUA.'^v.-BF 
VENDOR. D3- 

''  w9X  ^  *  9S  • 

C:CF_\_C.NDX 
DCR_CAGE . ND" 
-  S’_N_D.ND'<: 
-_E'<'_33.\:y 
-_CRD_D.n:^' 
N_NSN.NDX 
C  CCDE.NDX 
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System:  Automated  Vendor  Selection  Assistant 

Author:  Cant  Daniel  E.  Hagmaier 

index  Parameter  Summary 

Date:  7/30/91 

Time:  11:38 


N_NSN.NDX  --  Indexed  on:  NSN 

Used  in:  SCREENS. PPG  ■* 

used  in:  SELCTVEN.PRG 

V_C_M1L.NDX  --  Indexed  on:  cage+mi !_SDec 

Used  in:  SCREENS. PRG 
Used  in:  SELCTVEN.PRG 
Used  :n:  =REPVEN.PRG 

0CR_CAGE.NDX  --  Indexed  on:  CAGE 

Used  -n:  SCREENS. PRG 
used  in;  SELCTVEN.PRG 

CDCF_N_C.N0X  --  Indexed  on;  NSN+CAGE 

Used  in;  SCREENS. PRG 
.sed  -n;  PREPVEN.pRG 

P_C_COOE.NDX  --  Indexed  on:  CAGE^PR ;CE_CODE 
Used  in:  SELCTVEN.PRG 

0_CAGE.N0X  --  Indexed  on:  CAGE 
Used  -n:  .^REPVEN.pRG 

H_EXT_PR.NDX  --  Indexed  on;  ext_orice 
Used  in;  PREPVEN.pRG 

H_CRD_G.NDX  --  Indexed  on:  ORj_QUAN’' 

Used  ^n:  ^gEDVEN.PRG 
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HIST  N  O.NOX  —  Indexed  on:  NSN+DATE 


Used  in:  PREPVEM.P3G 


System:  Automated  Vendor  Selection  Assistant 
Author:  Caot  Daniel  E.  Hagmaier 
Procedures  Summary 
Date:  7/30/91 
Time:  11:38 


SCREENS. PRG 

Contains;  T’;T:.ESCR 
Cal’ea  by:  AVSA.PRG 
Contains:  INFO_SCR 
Called  by:  AVSA.PRG 
Contains:  INPUTSCR 
Called  by:  AVSA.PRG 
Contains:  SELCTSCR 
Cal'ed  by:  AVSA.PRG 
Contains:  NCVENSCR 
Called  by:  AVSA.PRG 
Contains:  PRiCESCR 
Called  by:  AVSA.PRG 
Contains:  VE.NDRSCR 
Called  by:  AVSA.PRG 
Contains:  ANALZSCR 
Called  by:  AVSA.PRG 
Contains:  INITLSCR 
■  Called  by:  AVSA.PRG 
Contains:  PR08MSCR 
Called  by:  AVSA.PRG 
Contains:  CDCFSCR 
Called  by:  AVSA.PRG 
Contains:  AWARDSCR 
Called  by:  AVSA.PRG 
Conta-ns;  RTDRN 

No  calls  to  this  orocedure 
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System:  Automated  Vendor  Selection  Assistant 
Author;  Cact  Daniel  E.  Hagmaier 
Tree  Diagram  for  databases  and  program  files. 
Date;  7/30/91 
Time;  11:39 


AVSA.PRG 

TlTLESCR'-procedure 
INFO_SCR--Drocedure 
INlTLSCR-'orocedure 
INPUTSCR--procedure 
SELCTSCR-'Orocedure 
SELCTVEN.PRG 
-->PR_''EMP.DBF 
-->NSN.DBF 
,->PRICE.DBF 
->DCRL.0BF 
-->VENDCR.DaF 
ANALZSCR-’Orocedure 
PREPVEN.PRG 
-->C0CF.DBF 
--XJUALITY.DBF 
-OVENOOR.OBF 
-->H0L0.^BF 
-->M00EL.DBF 
->H I  STORY. DBF 
PRICESCR-'Orocedure 
VENDRSCR-'orocedure 
CDCFSCR-'orocedure 
^ROBMSCR--orocsdure 
AWAROSCR'-procedure 
MCVENSCR-'orocedure 
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Appendix  E:  Variable  Descriptions 


Variable  Name 

Type 

Descriotion 

ANALZSCR 

Procedure  name. 

Informs  the  user  of  program  status 

AWARDSCR 

Procedure  name. 

Displays  the  user  Award  screen 

B 

dBase  work  area. 

C 

dBase  work  area. 

CDCFSCR 

Procedure  name. 

Displaying  CDCF  information 

CDCF_N_C 

CDCF  index  file. 

Indexed  on  NSN  and  Cage 

D 

dBase  work  area. 

DCRL 

Data  file. 

Contains  problem  vendor  info. 

DCRLCODE 

Data  file. 

Contains  DCRL  code  descriptions 

DCR_CAGE 

DCRL  index  file. 

Indexed  on  Cage  code 

HIST_N_D 

History  index  file. 

Indexed  on  NSN  and  Date 

HOLD 

Data  file. 

Temporary,  holding  price  info 

H_EXT_PR 

Hold  index  file. 

Indexed  on  extended  price 

H_ORD_Q 

Hold  index  file. 

Indexed  on  order  quantity 

INFO_SCR 

Procedure  name. 

Program  information  screen 

INITLSCR 

Procedure  name. 

Informs  the  user  of  program  status 

INPUTSCR 

Procedure  name. 

Controls  the  user  input  screens 

MCAGE 

Memory  variable. 

Contains  cage  code 

MCAGEl 

Memory  variable. 

Contains  first  cage  in  mem  matrix 

MCELL 

Program  pointer. 

Used  to  point  to  current  cell 

MCHOICE 

Memory  variable. 

Contains  user's  response 

MCOL 

Program  pointer. 

Tracks  the  current  matrix  column 

MCOLUMN 

Program  pointer. 

Tracks  memory  matrix  column 

MCONTtNUE 

Program  flag. 

Controls  internal  looping 

MCOUNT 

Counter  variable. 

Controls  matrix  development 

MCOUNTER 

Counter  variable. 

Controls  matrix  development 

MCURRENT 

Memory  variable. 

Contains  current  time 

MDAY 

Memory  variable. 

Numeric  value  of  today's  date 

MDELIVERY 

Memory  variable. 

The  total  days  for  vendor  delivery 

MEND 

Program  flag. 

Controls  internal  looping 
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MEP 

Memory 

variable. 

MEXT_1_1 

Matrix 

variable . 

MEXT_PRICE 

Memory 

variable. 

MFLAG 

Program  flag. 

MHISTORYl 

Program 

flag. 

MHIST0RY2 

Program  flag. 

MHIST_CAGE 

Memory 

variable. 

MHIST_DATE 

Memory 

variable. 

MHIST_PR 

Memory 

variable . 

MJ_DATE 

Memory 

variable. 

MLAST_ORD 

Memory 

variable. 

MLEAP_YR 

Program 

flag. 

MLINE 

Memory 

variable. 

MLOW 

Program 

flag. 

MLOW_PRICE 

Memory 

variable . 

MMAX 

Memory 

variable . 

MMIN 

Memory 

variable. 

MMONTH 

Memory 

variable . 

MNET_PRICE 

Memory 

variable . 

MNEW_NSN 

Program 

1  flag. 

MNEXTCOL 

Program 

flag . 

MNSN 

Memory 

variable . 

MODEL 

Data  file  name. 

MORDER 

Memory 

variable. 

MORDERl 

Memory 

variable. 

MORDER2 

Memory 

variable. 

MORDER3 

Memory 

variable . 

MORDER4 

Memory 

variable . 

MORDER5 

Memory 

variable . 

MORDER6 

Memory 

variable . 

MPRICE 

Memory  variable. 

Contains  extended  price 
Extended  price,  row  1,  column  1 
Contains  extended  price 
General  purpose  control 
Controls  Price  Exceeds  Hist,  msg. 
Controls  'No  Hist.  On  File’  msg. 
Most  recent  vendor  contracted. 
Most  recent  purchase  date. 

Most  recent  purchase  price. 
Contains  the  Julian  date. 

Use  for  matrix  development. 

Set  if  current  year  is  leap  year. 
Counter  for  matrix  development. 
Controls  Price  May  Be  To  Low  flag. 
Contains  lowest  purchase  price. 
Contains  ’QMAXn'  for  matrix. 
Contains  'QMINn'  for  matrix. 
Contains  current  month. 

Contains  net  price  for  display. 
Cleared  while  NSN  current. 
Controls  search  for  vendor  price. 
Contains  the  current  NSN. 

Contains  the  value  of  'ORDERn' 
Quantity  of  column  1  i.  matrix. 
Quantity  of  column  2  in  matrix. 
Quantity  of  column  3  in  matrix. 
Quantity  of  column  4  in  matrix. 
Quantity  of  column  5  in  matrix. 
Quantity  of  column  6  in  matrix. 
Contains  displayed  extended  price 
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MQUANT 

Memory  variable. 

MQUANTITY 

Memory  variable. 

MRDD 

Memory  variable. 

MRETURN 

Memory  variable. 

MROW 

Memory  counter. 

MSERIES 

Program  counter. 

MSETASIDE 

Program  flag. 

MSTOP 

Program  timer. 

MTIME 

Program  timer. 

MUNITS 

Memory  variable. 

MUNIT_PR 

Program  flag. 

MVALID 

Program  flag. 

MVARIATION 

Program  flag. 

MYEAR 

Memory  variable. 

NOVENSCR 

Procedure  name. 

N_NSN 

Index  file. 

PREPVEN 

Procedure  file. 

PRICESCR 

Procedure  name. 

PROBMSCR 

Procedure  name. 

PR_TEMP 

Data  file. 

P_C_CODE 

Prj.ce  index  file. 

Q  CAGE 

Quality  index  file 

RTURN 

Procedure  name. 

SCREENS 

Procedure  file. 

SELCTSCR 

Procedure  name. 

SELCTVEN 

Procedure  file. 

TITLESCR 

Procedure  name. 

VENDRSCR 

Procedure  name. 

V  C  MIL 

’\/endor  index  file. 

Contains  quantity  being  sold. 
Amount  requested  by  user. 
Contains  required  delivery  date. 
Contains  the  last  viewed  screen. 
Tracks  the  current  matrix  row. 
Tracks  the  vendors  price  breaks. 
Set  if  procurement  is  Set-A-Side. 
Time  which  warning  messages  end. 
Current  system  time. 

Contains  number  of  lots  required. 
Controls  pricing  screen. 

Set  when  NSN  is  in  the  data  file. 
Controls  display  of  ’Exceeds’  msg. 
Contains  current  year. 

Displays  ’No  vendor  available’. 
Used  by  NSN,  indexed  on  NSN. 
Prepares  vendor  data  for  display. 
Displays  unit  and  extended  prices. 
Displays  problem  vendor  info. 
Contains  temp  vendors  and  S  data. 
Indexed  on  cage  code. 

Indexed  on  cage  code. 

Called  when  escape  key  pressed. 
Contains  screen  display  programs 
Informs  user  of  program  status. 
Selects  bidding  vendors. 

Displays  title  screen. 

Display  vendor  info  screen, 
indexed  on  cage,  mii_spec. 
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Appendix  F: 

Data  Field  Descriotions 

Field  Name 

Database 

Description 

ADDED 

DCRL.DBF 

Date  when  vendor  added  to  the  DCRL  file 

ADDRESSl 

VENDOR. DBF 

First  line  of  vendors  business  address 

ADDRESS2 

VENDOR. DBF 

Second  line  of  vendors  business  address 

ADDRESS3 

VENDOR. DBF 

Third  line  of  vendors  business  address 

ADDRESS4 

VENDOR. DBF 

Forth  line  of  vendors  business  address 

ALT 

MODEL. DBF 

Administrative  Lead  Time  for  award  paper 
work 

CAGE 

PR  TEMP. DBF 
HOLD. DBF 
NSN.DBF 

VENDOR. DBF 
DCRL.DBF 

CDCF. DBF 

PRICE. DBF 
QUALITY. DBF 
HISTORY. DBF 

Vendors  cage  code,  unique  to  each  vendor 

CATEGORY  1 

DCRL.DBF 

First  vendor  problem 

CATEGORY 2 

DCRL.DBF 

Second  vendor  problem 

CATEGORY3 

DCRL.DBF 

Third  vendor  problem 

CATEGORY4 

DCRL.DBF 

Forth  vendor  problem 

CATEGORY 5 

DCRL.DBF 

Fifth  vendor  problem 

CATEGORY6 

DCRL.DBF 

Sixth  vendor  problem 

CAUSE 

CDCF. DBF 

Reason  for  discrepancy 

CAUSE  CODE 

CDCF. DBF 

Code  identifying  discrepancy 

CDCF 

PR_TEMP.DBF 

Flag  set  if  vendor  found  in  CDCF  file 

CHANGED 

DCRL.DBF 

Date  the  record  was  updated 

CODE 

DCRLCODE.DBF 

The  code  letters  found  in  the  DCRL  file 

CORR 

CDCF. DBF 

Correction  description 

CORR_CODE 

CDCF. DBF 

Correction  Code 

DATE 

HISTORY. DBF 

Julian  date  of  item  purchase 

DATEl 

DCRL.DBF 

Date  first  vendor  problem  entered 

DATE2 

DCRL.DBF 

Date  second  vendor  problem  entered 

DATE3 

DCRL.DBF 

Date  third  vendor  problem  entered 

DATE4 

DCRL.DBF 

Date  fourth  vendor  problem  entered 
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DATES 

DCRL.DBF 

Date  fifth  vendor  problem  entered 

DATES 

DCRL.DBF 

Date  sixth  vendor  problem  entered 

DAYS 

VENDOR. DBF 

Number  of  days  to  qualify  for  payment 
discount 

DELIVERY 

VENDOR. DBF 

Number  of  days  to  deliver  an  order 

DEL_IND 

DCRL.DBF 

DISC 

VENDOR. DBF 

Discount  offered  prompt  Payment 

DISC 

CDCF.DBF 

Discrepancy  description 

DISC_CODE 

CDCF.DBF 

Discrepancy  code 

DISP 

CDCF.DBF 

Disposition  description 

DISP  CODE 

CDCF.DBF 

Disposition  code 

EXT_PRICE 

HOLD. DBF 

Extended  price  of  a  quantity  of  product 

FOB 

VENDOR. DBF 

Vendor  identified  FOB  point 

FSC 

QUALITY. DBF 

Federal  Stock  Class  vendor  qualified  on 

HISTORY 

PR  TEMP. DBF 

Flag  identifying  historical  problems 

HISTORY  1 

MODEL. DBF 

Limit  current  price  can  exceed  historical 
price 

HISTORY2 

MODEL. DBF 

Price  limit  for  item  not  on  file 

INSPECT 

VENDOR. DBF 

Reserved  for  vendor  inspection  informa 
t  ion 

LOT_SIZE 

VENDOR. DBF 

Purchase  requirements 

LOW 

MODEL. DBF 

Controls  the  low  price  highlight 

MIL  SPEC 

PR  TEMP. DBF 
NSN. DBF 

VENDOR. DBF 

MilSpec  of  item 

MIN  ORDER 

VENDOR. DBF 

Dollar  amount  of  vendor  minimum  order 

NAME 

VENDOR. DBF 

Name  of  vendor 

NAMEl 

DCRL.DBF 

First  line  of  vendor  address 

NAME2 

DCRL.DBF 

Second  line  of  vendor  address 

NAME  3 

DCRL.DBF 

Third  line  of  vendor  address 

NAME4 

DCRL.DBF 

Fourth  line  of  vendor  address 

NET 

VENDOR. DBF 

Number  of  days  payment  is  due  to  the 
vendor 
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NSN 

NSN. DBF 
CDCF.DBF 
HISTORY. DBF 

NSN  of  the  item 

ORD_QUANT 

HOLD. DBF 

Quantity  of  product  being  analyzed 

PRICE 

HISTORY.  DBF 

Previous  purchase 

price  of  item 

PRICEl 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

first  price  block 

PRICEIO 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

tenth  price  block 

PRICE2 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

second  price  block 

PR1CE3 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

third  price  block 

PRICE4 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

forth  price  block 

PRICES 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

fifth  price  block 

PRICES 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

sixth  price  block 

PRICE7 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

seventh  price  block 

PRICES 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

eighth  price  block 

PRICES 

PR  TEMP. DBF 
PRICE. DBF 

Extended  price  of 

ninth  price  block 

PRICE  CODE 

PR  TEMP. DBF 
NSN. DBF 

PRICE. DBF 

Code  linking  an  item  to  a  price  group 

PROS 

PR_TEMP.DBF 

Flag  set  if  vendor  found  in  DCRL  file 

QMAXl 

PR  TEMP. DBF 
PRICE. DBF 

Max  Purchase  quantity  for  price  block  one 

QMAXIO 

PR  TEMP. DBF 
PRICE . DBF 

Max  Purchase  quantity  for  price  block  ten 

QMAX2 

PR  TEMP. DBF 
PRICE. DBF 

Max  Purchase  quantity  for  price  block  two 

QMAX3 

PR  TEMP. DBF 
PRICE . DBF 

Max  Purchase  qnty 

for  price  block  three 

gMAX4 

PR  TEMP. DBF 
PRICE. DBF 

Max  Purchase  qnty 

for  price  block  four 

QMAX5 

PR  TEMP. DBF 
PRICE . DBF 

Max  Purchase  qnty 

for  price  block  five 
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QMAX6 

PR  TEMP. DBF 
PRICE. DBF 

Max  Purchase  quantity  for  price  block  six 

QMAX7 

PR  TEMP. DBF 
PRICE. DBF 

Max  Purchase  qnty  for  price  block  seven 

QMAX8 

PR  TEMP. DBF 
PRICE. DBF 

Max  Purchase  qnty  for  price  block  eight 

QMAX9 

PR  TEMP. DBF 
PRICE. DBF 

Maximum  Purchase  quantity  for  price  block 
nine 

QMINl 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
one 

QMINIO 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
ten 

QMIN2 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
two 

QMIN3 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
three 

QMIN4 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
four 

QMIN5 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
five 

QMIN6 

PR  TEMP. DBF 
PRICE .DBF 

Minimum  Purchase  quantity  for  price  block 
six 

QM1N7 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
seven 

QMIN3 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
eight 

QMIN9 

PR  TEMP. DBF 
PRICE. DBF 

Minimum  Purchase  quantity  for  price  block 
nine 

QTY  VAR_M 

VENDOR. DBF 

Percent  the  vendor  can  ship  under 
requested  amt 

QTY  VAR  P 

VENDOR. DBF 

Percent  the  vendor  can  ship  over  request 
ed  amt 

QUALITY 

PR_TEMP.DBF 

Flag  indicating  vendor  was  found  in 
Quality  file 

QUANTITY 

HISTORY. DBF 

Number  of  items  purchased 

REMITl 

VENDOR. DBF 

Vendor’s  billing  address,  line  1 

REMIT2 

VENDOR. DBF 

Vendor's  billing  address,  line  2 

REMIT3 

VENDOR. DBI 

Vendor’s  billing  address,  line  3 

REMIT4 

VENDOR. DBF 

Vendor's  billing  address,  line  4 

RESTRICTl 

DCRL.DBF 

First  line  of  vendor  restrictions 
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RESTRICT2 

DCRL.DBF 

Second  line  of  vendor  restrictions 

RESTRICT3 

DCRL.DBF 

Third  line  of  vendor  restrictions 

RESTRICT4 

DCRL.DBF 

Forth  line  of  vendor  restrictions 

RESTRICTS 

DCRL.DBF 

Fifth  line  of  vendor  restrictions 

RFCC 

VENDOR. DBF 

RFCC  code  used  by  the  vendor 

SIZE_CODE 

VENDOR. DBF 

Code  indicating  vendor's  status  (See  DESC 
Form  800) 

STATE 

VENDOR. DBF 

Government  state  code  for  vendor's  resid 
ance 

TITLE 

DCRLCODE.DBF 

Long  description  of  DCRL  codes 

UI 

VENDOR. DBF 

Unit  of  issue 

UNIT_PRICE 

HOLD. DBF 

Unit  price  of  an  item 

UP_LIMIT 

MODEL. DBF 

Maximum  amount  of  small  contract  awards 

VENDOR 

QUALITY. DBF 

Cage  code  of  vendor 
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Appendix  G:  Questionnaire  Responses 


PANEL  QUESTIONNAIRE  RESPONSES 

1 .  Describe  any  problems  you  incurred  while  using  the  system? 
None 


What  information  presented  by  the  system,  if  any,  is  irrelevant  to  the  award 
selection  process? 

Required  delivery,  although  not  irrelevant,  is  not  looked  at 
as  closely  as  low  bidder. 

The  input  of  a  RDD  date;  awards  are  not  usually  based  on 
this. 


3.  What  other  information  should  the  system  provide  to  aid  in  the  award  process? 

Should  provide  quantity  in  past  procurement  history.  This 
has  a  direct  bearing  on  award  process  when  making  total 
comparison  of  unit  prices  that  exceed  10%. 

Designate  vendors  who  have  minimum  by  quantities.  Add 
quantity  purchased  in  last  buy  block  info. 

4.  Do  you  have  any  suggestions  for  future  enhancements  to  this  system? 

None 


5.  Do  you  have  any  other  comments  or  suggestions  regarding  the  design  or 
usefulness  of  this  system? 

It  certainly  saves  time  and  effort.  The  overall  view  of  the 
extension  screens  is  great.  Program  is  very  well  written. 
Computer  instructions  are  easy  to  follow. 
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It  will  be  very  beneficial  and  useful  to  all  buyers  using 
price  lists  as  we  now  have.  The  major  concern  would  be 
pricing  updates  and  how  they  would  be  done. 

As  presented  today,  does  the  system  assist  the  buyer  in  the  vendor  selection 
process? 


Yes,  definitely. 


BUYER  QUESTIONNAIRE  RESPONSES 


1.  Describe  any  problems  you  incurred  while  using  the  system? 
None. 

None. 

So  far,  none. 

None. 

None. 

One  was  hitting  a  wrong  key  which  put  me  "back"  tempo¬ 
rarily  on  a  couple  of  PR’s.  Also,  noticed  that  QPL 
(Qualified  Sources)  sources  were  not  indicated  and  noticed 
that  there  was  no  indication  that  government  source 
inspection  was  acceptable  to  the  contractor(s)  for  supplying 
the  parts. 

Need  P.O.C.  &  phone  numbers  for  the  contractors.  At 
award  step,  need  a  definitive  key  that  restarts  the  system 
due  to  accidently  hitting  a  key,  besides  "P",  and  not  being 
finished.  Switching  from  U  screen  to  E  screen  comparing 
low  bid  to  delivery,  the  U  screen  should  have  the  info  on 
meeting  RDD  also. 

None. 

N/A. 

None. 

None. 

None, 


Didn't  have  any  problems. 


What  information  presented  by  the  system,  if  any,  is  irrelevant  to  the  award 
selection  process? 

None. 

None. 

No  Change. 

Request  for  Required  Delivery  Date  (RDD).  Not  that  the 
RDD  is  not  important.  I  just  don’t  think  we  use  it  to 
determine  the  awardee  over  another,  under  normal  situa¬ 
tions. 

None. 

Although  delivery  is  important,  I  think  RDD  info,  is  not 
that  relevant  to  this  situation.  If  delivery  is  urgent,  would 
not  be  bought  as  price  listed  item. 

None. 

Thought  all  the  information  was  relevant. 

Set-aside,  if  a  large  business  is  low,  the  set-aside  should  be 
dissolved  and  not  continued. 

None. 

None. 

None. 

None. 

The  RDD  has  not  been  a  priority  when  deciding  what 
contractor  receives  the  award.  Delivery  is  important 
however,  price  is  mostly  the  determining  factor.  This  is 
not  irrelevant  information  Just  over  emphasized  in  the 
system. 
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3. 


What  other  information  should  the  system  provide  to  aid  in  the  award  process? 


DCAS  information. 

More  infer,  on  past  history. 

Combined  PR. 

None. 

Last  buy  qty. 

FOB  origin  should  designate  city  &  state. 

Pre-award  information  -  Are  there  any  problems  with  a 
certain  vendor(s)  -  They  should  be  identified. 

Technical  infoimation  -  The  QPL  items  should  have  the 
qualified  sources  identified  along  with  the  current  QPI 
info,  (specs).  In  addition,  the  system  could  indicat 
whether  a  contractor(s)  has  accepted  government  source 
inspection  (Y  or  N)  and  if  there  is  any  lot  charge  associat¬ 
ed. 

Packaging  information  -  The  system  should  indicate 
whether  a  certain  company  can  comply  with  Mil  packaging 
requirements  &  bar  coding  requirements  &  whether  it  is 
done  at  its  facility  or  farmed  out.  (Important  if  GSl  is 
implemented). 

When  several  P/N’s  are  acceptable  for  a  particular  NSN, 
how  do  the  buyers  know  which  part  dealers  are  quoting. 
Same  is  true  of  MIL-SPEC  items;  the  sample  PR’s  used 
dealers  as  vendors  given.  To  write  up  the  award  buyers 
need  to  know  which  mfg.  they  are  quoting. 

P.O.C.  for  contractors.  Phone  numbers.  If  there  is 
alternate  bids  that  due  to  dollar  savings  should  be  evaluat¬ 
ed.  to  enhance  competition.  How  long  are  the  quotes  valid 
for. 

RFQ  s  have  other  requirements  than  NSN.  Qty.  &  delivery 
date  req'd  -  specifically:  I)  FOB  point  request.  2)  inspec¬ 
tion  &  acceptance  point.  3)  packaging  &  marking  reqmt’s 
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all  vary.  Also,  we  must  know  (if  awarding  to  dealers) 
whose  mfg  part  will  be  supplied,  as  there  is  a  great 
possibility  that  more  than  one  mfgr.  is  approved. 

Prices  if  place  of  Inspection  and  Acceptance  is  Origin,  as 
well  as  the  U/P  if  the  place  of  inspection  is  destination. 
Phone  U  and  contact  point  for  each  vendor.  The  inclusion 
of  the  Contractor’s/Vendor’s  phone  #  might  help  aid  the 
buyer  if  he/she  needs  to  contact  C/V  for  any  reason. 
Could  be  included  with  address  of  vendor  (screen). 

U/P  w/GSI  -  if  there’s  a  charge  for  GSI.  Where  insp- 
/accep  is  to  be  performed  (i.e.  contractor’s  plant,  pkgr’s 
plant,  name  and  address  of  pkgr).  Previous  buy  -  "Last 
Purchased  On  .  .  .  should  include  qty  and  P.O. /Contract 
it. 

Somehow  interaction  time  between  the  contract  specialist 
and  the  contractor  must  be  accounted  for  in  the  system  as 
well  as  time  spent  for  inner  office  communications  between 
the  buyer  and  item  manager  or  technician.  The  buyer 
needs  some  type  of  authority  to  change  for  example  FOB 
point/inspection  qty  variance  to  tailor  each  quote  to  each 
award. 

One  of  the  QPL  source  price  list  was  not  written  on 
abstract.  All  of  the  vendors  should  have  been  on  there. 
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4. 


Do  you  have  any  suggestions  for  future  enhancements  to  this  system? 


Not  at  this  time. 

Not  yet. 

None. 

No. 

Yes.  A  company’s  certs  and  reps  could  be  input  for  those 
buys  between  $10,000  and  $25,000  by  company  officials 
when  they  "feed  DESC  price/del."  info. 

Need  P.O.C.  from  contractors.  Quote  expiration  date. 
Have  a  definitive  key  that  will  restart  the  system  at  award 
stage  in  lieu  of  just  hitting  any  key  besides  "P".  If  low 
bidder  on  U  screen  does  not  meet  RDD  there  should  be  a 
method  of  annotating  such  in  lieu  of  needing  to  go  to  the  E 
screen. 

Whose  mfg.  part  will  be  supplied,  as  there  is  a  great 
possibility  that  more  that  one  mfgr.  is  approved. 

The  screen  that  shows  last  buy  info  might  state  the  quantity 
bought  (as  of  now  it  Just  states  when  the  last  buy  was  and 
the  price  paid). 

Have  Form  800  in  the  system  where  information  can  be 
transferred  and  then  print  Form  800. 

As  described  in  previous  block,  it  would  be  beneficial  for 
the  buyer  to  be  able  to  make  unilateral  changes  to  only 
change  certain  contents  of  the  contractor’s  quotation  so  the 
terms  of  each  quotation  would  apply  and  serve  the  govern¬ 
ments  needs  i.e.  INSP/ACC  pt,  qty  variance. 

No.  1  really  don't  know  that  much  about  it  yet. 


G-7 


Do  you  have  any  other  comments  or  suggestions  regarding  the  design 
usefulness  of  this  system? 

No. 

This  will  be  a  good  thing  to  have. 

Not  yet. 

This  system  is  a  leadtime  saver.  It  deletes  the  solicitation 
leadtime  and  enhances  the  award  process  all  at  the  same 
time. 

Great  idea.  Very  helpful. 

It’s  a  great  improvement  over  price  lists. 

The  usefulness  of  the  system  is  very  good  and  has  numer¬ 
ous  possibilities.  Good  idea! 

Think  the  system  could  be  very  useful  to  buyers  in  most 
cases.  Is  there  a  way  to  include  low  offerers  quoting  alter¬ 
nate  part  numbers,  which  happens  every  so  often.  The 
price  screens  showed  min  buy  qty  for  several  vendors,  how 
would  minimum  dollar  amount  per  line  item  be  reflected. 

Would  be  excellent  for  price  listed  QPL’s,  however  due  to 
the  nature  of  the  beast  (shady  contractors  &  reps)  these 
should  be  followed  up  in  some  manner  so  that  there  would 
be  some  written  backup  to  ensure  the  quoter’s  could  not 
repjeatedly  claim  typo  errors  which  would  m  turn  create  a 
nightmare  for  the  post-award  personnel.  Could  make  these 
all  bilateral  contracts/purchase  orders  since  we  would  have 
it  all  in  the  computer  system  and  the  time  involved  would 
be  offset  by  the  results  of  the  written,  legal,  obligations. 

Very  useful  tool!  This  would  greatly  decrease  PALT. 

Could  be  very  useful  -  depends  on  how  often  computer  is 
up-and-running. 

Having  three  years  experience  with  DPACS  (DPACS  is  a 
step  up  from  manual  buying  when  it  works)  and  only  a 
short  time  with  the  Automated  Vendor  Selection  Assistant. 


it  looks  like  DPACS  may  have  some  competition.  Hope 
this  system  works. 

I  think  it  is  a  step  in  the  right  direction,  however  it  will 
take  time  to  improve  and  perfect.  Their  must  be  a  way  to 
monitor  the  accuracy  of  the  user  as  well  as  an  allotment 
built  in  to  the  system  for  the  time  spent  for  the  extra  steps 
and  unique  situations  that  arise  on  each  procurement. 
Their  must  also  be  allowances  made  for  computer  down 
time.  Overall  at  least  at  its  inception  this  process  needs  to 
be  monitored  closely  by  management  to  assure  fairness. 

The  program  seems  to  be  really  easy.  And  that  helped  a 
lot.  The  program  could  be  very  useful  because  could  save 
on  the  buyer'  time  &  mind.  Manual  written  QPL’a  are 
very  bonng  and  monotonous. 
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Disclaimer 


This  software  was  developed  for  the  exclusive  use  of  the  Defence  Electronic 
Supply  Center  (DESC),  for  demonstration  poroses  only.  It,  in  its  current  configuration, 
is  not  intended  to  be  used  in  the  in  the  actual  vendor  selection  decision  process.  The 
user  assumes  responsibility  of  any  such  employment. 
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Introduction 


This  guide  is  designed  to  pilot  the  user  through  the  use  of  the  Automated  Vendor 
Selection  Assistant  Program.  The  software,  at  the  time  of  this  writing,  is  not  intended 
for  use  as  a  stand  alone  program.  Its  purpose  was  to  establish  validity  for  the  concepts 
presented  in  the  VASPP  program.  As  a  result,  links  to  the  actual  supporting  data  files 
have  been  simulated. 

As  the  VASPP  system  evolves,  it  is  envisioned  only  the  ideas  generated  by  this 
prototype  will  survive.  The  tasks  accomplished  by  the  Automated  Vendor  Selection 
Assistant  software  are  a  subset  of  those  required  by  VASPP.  As  such,  it  is  expected  this 
code  will  be  re-written  in  the  native  language  of  VASPP,  when  that  stage  of  VASPP 
development  is  reached. 
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System  Requirements 


The  Automated  Vendor  Selection  Assistant  program  is  designed  to  run  on  a  stand 
alone  personal  computer  system.  It  was  developed  on  a  286,  AT  class  machine.  A  hard 
disk  drive  is  required.  The  supporting  program  and  data  files  consume  six  megabytes 
of  disk  space.  In  addition  to  the  program  files,  dBase  III  Plus,  must  reside  on  the 
system.  A  color  monitor  is  recommended,  but  not  required.  There  are  no  provisions 
in  the  system  to  produce  printed  images,  therefor  a  line  printer  is  not  required. 

Due  to  the  system  dependance  o.’  data  files  for  information,  performance  of  the 
hard  drive  will  directly  affect  software  performance.  As  such,  it  is  suggested  a  'File 
Defragmation'  utility  be  used  on  the  hard  drive  before  installing  the  software. 


Software  Installation 


The  Automated  vendor  selection  Assistant  contains  program  and  database  files. 
They  should  be  installed  in  their  own  directory,  on  the  same  disk  drive  that  dBase 
resides.  There  is  no  requirement  to  keep  the  program  files  separate  from  the  data  files. 
See  your  DOS  manual  for  information  on  creating  subdirectories  and  copying  files. 
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Starting  AVSA 


The  Automated  Vendor  Selection  Assistant  (AVSA)  must  run  in  conjunction  with 
dBase  III  Plus.  Earlier  versions  of  dBase  are  incompatible  To  begin  program 
execution,  dBa.se  must  first  be  running  on  the  computer  system.  Please  refer  to  your 
program  manual  for  instructions  regarding  the  installation  and  operating  of  dbase  III 
Plus. 

At  the  dhase  dot  prompt,  the  following  command  need  to  be  entered; 

SET  PATH  TO  useroption 

where  user  option  is  the  full  directory  path  to  the  AVSA  files.  For  example,  if  the  files 
are  stored  in  the  subdirectory  ’AVSA’  on  disk  drive  ’C,  the  command  would  be  entered 
as  follows; 

SET  PATH  TO  C:\AVSA 

With  the  path  set.  AVSA  can  be  started.  To  start  AVSA.  the  command; 

DO  AVSA 

IS  entered.  This  will  bring  up  the  welcome  screen.  The  following  pages  will  describe 
the  program  operation. 
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User’s  Screens 
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Welcome  Screen 


Welcome  To  The 

AUTOMATED 

VENDOR 

SELECTION  [ 

assistant  I 

1 

! 

Beta  Version  2.5 

r 

k 

Press  Any  Key  To  Continue 


This  is  the  opening  screen  providing  program  identification.  The  user  strikes  any 
key  to  proceed  to  the  next  screen. 
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Program  Information  Screen 


The  Automated  Vendor  Selection  Assistant 
selects  the  vendor(s)  who  have  competitively  bid 
on  the  item  of  interest. 

To  proceed,  you  must  know  the  item's  N3N 
and  the  quantity  required. 


Do  you  wish  to  continue?  <Y/N> 


This  screen  explains  the  purpose  and  identifies  the  information  required  from  the 
user  for  successful  program  execution.  The  user  decides  whether  to  continue  on  into  the 
program  or  terminate  and  return  to  the  DOS  prompt. 
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Initializing  Screen 


Initializing  The  System 


This  is  a  program  status  screen.  After  the  user  informs  the  system  to  proceed, 
this  screen  is  displayed  while  meir.ory  variables  are  being  initialized.  It  will  appear 
briefly  prior  to  entering  the  NSN  each  time.  The  duration  that  this  screen  is  displayed 
is  dependant  uptm  the  speed  of  the  computer  system. 
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NSN  Screen 


Enter  the  NSN  of  the  item  to  be  procured 
5905-01-009-5543 

- (Press  <CR>  when  complete) - 


Press  <ESC><ESC>  to  Quit  the  Assistant 


This  is  the  first  of  the  input  screens.  Prompts  for  information  are  presented 
sequentially.  The  first  item  requested  is  the  NSN.  The  user  enters  the  thirteen  digits, 
the  system  supplies  the  Only  numerics  are  accepted.  The  user  can  use  the  arrow 
keys  to  make  corrections  in  the  entry.  When  the  NSN  is  complete,  pressing  a  carriage 
return  <CK>  enters  it  into  the  system.  The  system  then  checks  to  see  if  the  NSN 
matches  an  entry  in  the  pricing  data  file.  If  no  match  is  found,  a  warning  message  is 
displayed  and  the  u.ser  is  allowed  to  re-enter  the  NSN.  If  the  NSN  is  on  tile,  the  system 
prompts  the  user  for  the  quantity  required. 

To  terminate  the  entry,  the  escape  key  <  ESC>  is  pressed  twice.  The  entry  can 
be  terminated  at  any  time  while  the  user  is  imputing  the  NSN.  If  the  user  elects  to  end 
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the  session  prematurely,  the  system  resets  to  the  Program  Information  Screen.  At  the 
information  screen,  the  user  can  start  another  inquiry  or  exit  to  the  dBase  prompt. 
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Quantity  Screen 


Enter  the  MSN  of  the  item  to  be  procured 


5905-01-009-5543 


Enter  the  quantity  required 


90  EA. 

(Press  <CR>  when  complete) 


Enter  <0><CR>  To  Quit 


After  a  NSN  is  entered  that  the  system  recognizes,  the  user  is  prompted  for  the 
number  of  item  required.  Only  numerics  entries  are  accepted.  When  the  correct  value 
IS  entered,  the  user  presses  the  carriage  return  <CR>.  If  the  user  wishes  to  end  the 
session  prematurely,  a  zero  <()>  may  be  entered.  Entering  a  zero  will  return  the 
system  to  the  Program  Information  Screen  where  the  user  can  either  restart  the  inquiry 
or  exit  the  system  entirely  . 
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RDD  Screen 


r 

I  Enter  the  NSN  of  the  item  to  be  procured 

I 

1 

i  5905-01-009-5543 

I 

I  Enter  the  quantity  required 


90  EA. 

(Press  <CR>  when  complete) 


What  is  the  RDO  date’  92105 


The  Required  Delivery  Date  (RDD)  is  (he  next  item  requested  by  the  system. 

A  numeric  value  is  entered.  The  first  two  digits  (in  this  case  '92’)  represent  the  year  that 
the  items  are  required.  Th-  next  three  digits  (105)  indicates  the  day  of  the  year  the  item 
IS  required  Any  year  is  valid  from  one  year  prior  to  the  current  year  to  ninety-nine. 
Valid  day  entries  range  from  zero  to  305  (300  during  a  leap  year). 

This  date  is  used  a  target  date  for  vendor  delivery.  For  more  information  on  the 
use  of  the  RDD.  refer  to  the  Vendor  Detail  Screen. 
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Set-A-Side  Screen 


Enter  the  NSN  of  the  item  to  be  procured 
5905-01-009-5543 

Enter  the  quantity  required 
90  EA. 


(Press  <CR>  when  complete) 


Is  this  procurement  Set-Aside  for  small  business’’  <Y/N/?> 


The  systc  n  uses  the  information  provided  in  this  entry  to  exclude  large  vendors 
from  consideration  if  a  'Y'  is  entered.  Otherwise,  all  vendors  bidding  on  the  item  of 
interest  are  examined.  If  the  user  is  unsure  if  the  request  has  been  identified  as  a  Set-A- 
.Side.  a  can  be  entered.  This  is  functionally  equivalent  to  entering  a  ’N',  as  all 
vendors  bidding  on  the  item  are  examined. 

This  IS  the  last  of  the  input  screens.  From  this  point,  the  system  assumes  control, 
displacing  status  screen  as  the  processing  evolves.  Depending  on  the  relative  speed  of 
the  system  and  the  si/e  of  the  data  tiles  m  use.  processing  may  take  from  one  to  several 
minutes. 
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Selecting  Vendors  Screen 


Selecting  Vendors 


This  program  status  screen  informs  the  user  the  program  is  in  the  process  of 
interrogating  the  NSN  data  tile  looking  for  qualified  vendors  that  have  bid  on  the  item 
of  interest.  Vendors  that  are  currently  in  a  'DeBarred'  status  are  removed  from 
consideration.  'Targe'  vendors  are  also  removed  if  the  procurement  is  designated  as 
Set-A-Side"  If  the  system  fails  to  kKate  a  qualified  vendor,  a  message  to  that  effect  is 
displayed.  If  the  system  finds  at  least  one  qualified  vendor  the  program  status  screen  is 
updated. 
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No  Qualified  Vendor  Screen 


No  qualified  vendors 
are  on  file  matching 
your  requirements. 

Press  Any  <ey  To  Continue 


If  there  are  no  qualified  vendors  bidding  on  the  item,  the  user  is  informed  with 
the  presents  of  the  above  screen.  When  the  user  presses  a  key,  the  system  returns  to  the 
Program  Information  Screen.  From  this  point,  the  user  can  either  fail  to  make  the  award 
or  can  revise  the  requirements  (i.e.  specifying  that  the  procurement  is  not  limited  to 
small  vendors)  and  reprocess  the  request. 
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Analyzing  Vendor(s) 


Tlie  system  informs  the  user  it  has  successfully  located  at  least  one  qualified 
vendor  for  further  consideration  by  displaying  this  screen.  Any  vendors  remaining  after 
the  selection  process  are  analyzed  for  past  contract  performance.  The  DCRL  and  Quality 
data  files  are  scanned.  If  any  irregularities  are  found,  the  system  sets  internal  flags  to 
display  appropriate  messages  on  the  following  user  screens. 

After  reviewing  the  vendors  background,  the  system  focuses  on  pricing 
information.  The  minimum  order  quantity  is  calculated.  This  check  considers  vendor 
lot  size  and  minimum  order  dollar  amount.  Price  breaks  for  larger  purchases  are 
identified  as  well. 
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Organizing  Data  Screen 


Organizing  Vendors 


Once  background  checks  are  made  for  each  vendor,  and  price  information  is 
recorded,  the  system  moves  into  the  final  phase  of  processing.  The  Organizing  Vendor 
screen  is  displayed  at  this  time.  The  system  is  preparing  the  data  for  display  in  the 
following  screens. 
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Unit  Pricing  Screen 


***  UNIT  PRICE  EXCEEDS  HISTORY  *•*  Last  Purchas<*d  On  80302 

From  91637  For  $0.27 


Unit  Pricing  Data  For:  5905-01-009-5543 


90  100 

200 

250 

300 

500 

56856 

6S315 

7KS45 

1.43001  1.1400 

!  0.9200 

0.8500 

1.0200 

0.7800 

0.9000 

0.7700 

0.2720 

i 

1 _ 

VENDOR:!  Problem  Vendor  Info 

1  CDCF  Vendor  Info 

1  Qua  I i ty  Vendor 

PRICE:  rricfc  May  Be  To  Low 

1  Low  Price 

1 

<E->  Extend-  J  Pri-iny  <A>  Award  Screen  <C>  CDCF  Vendor  Detail 

<V>  Vendor  Information  <Q>  Quit  <P>  Problem  Vendor  Detail 


The  first  user  screen  presented  is  tne  Unit  Pricing  Screen.  This  screen  iin'orms 
the  user  which  vendors  sell  the  item,  and  the  unit  price  they  charge  for  each  unit.  The 
vendor's  cage  code  is  coior  ci'-ded.  corresponding  the  vendor's  appearance  in  the  DCRL 
data  file,  the  UDCF-  file  or  the  Quality  tile.  The  logic  governing  the  color  coc.?  assigned 
lo  each  vendor  has  a  designated  order  of  hierarchy.  The  Coding  for  a  vendor  found  in 
the  CDCF  file  will  override  an  appearance  in  the  Quality  file.  Accordingly,  an 
appearance  in  the  DCRL  data  file  will  override  all  other  color  coding. 

Pricing  information  is  alsti  color  coded.  The  low'esi  otal  price  to  satisfy  the 
purchase  request  is  highlighted  m  bright  green.  If  there  is  a  tie  between  vendors,  both 
low  quotes  will  be  highlighted.  If  the  low  price  is  'considerably'  lower  than  the  next 
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lowest  vendor’s  price,  the  low  price  is  highlighted  yellow.  This  feature  alerts  the  user 
that  the  price  may  be  unrealistic.  The  threshold  of  the  low  price  is  controlled  by  the 
model  database. 

Historical  information  regarding  past  procurement  of  the  item  are  displayed  in  the 
upper  right  hand  corner  of  the  screen.  This  feature  provides  the  user  with  not  only  the 
vendor  and  price  of  the  last  order,  but  provides  a  estimate  regarding  the  rate  of  item 
consumption. 

The  upper  left  hand  corner  is  a  message  area.  Any  irregularities  identified  by  the 
system  during  its  analysis  of  the  data  are  displayed  here.  These  are  cautionary  messages, 
alerting  the  user  to  potential  problems  with  the  requirement.  (Refer  to  the  Model 
Component  for  further  explanation  of  these  messages.) 

An  option  menu  is  located  at  the  bottom  of  the  screen.  While  this  screen  appears 
on  most  of  the  user  screens,  the  options  available  change,  depending  on  the  user  screen 
currently  being  displayed.  From  the  unit  price  screen  the  user  may  transfer  to  the 
following  screens:  Extended  Pricing  screen.  Vendor  Detail  screen,  CDCF  Vendor  Detail 
screen.  Problem  Vendor  Detail  Screen,  and  the  Award  screen,  or  return  to  the  Program 
Information  Screen. 
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Extended  Pricing  Screen 


**•  UNIT  PRICE  EXCEEDS  HISTORY  ***  Last  Purchased  On  80302 

From  91637  For  $0.27 


Extended  Pricing  Data  For:  5905-01-009-5543 


90 

100 

200 

250 

300 

500 

56856 

6S313 

7K545 

128.70 

114.00 

92.00 

170.00 

255.00 

234.00 

450.00 

385.00 

136.00 

■ 

■ 

PRICE:!  Price  May  Be  To  Low  1 

1  Low  Price 

xLI>  Unit  Pricing  <A>  Award  Screen  <C>  CDCF  Vendor  Detail 

<V>  Vendor  Information  <Q>  Quit  <P>  Problem  Vendor  Detail 


This  is  the  extended  pricing  screen.  All  information  contained  on  it  is  the  same 
as  for  the  unit  pricing  screen  with  two  exceptions.  First,  the  numbers  contained  in  the 
matrix  now  represent  the  extended  price  information.  It  is  calculated  by  taking  the  unit 
price  for  a  given  quantity  and  multiplying  it  by  the  quantity  shown  in  the  column 
headings.  This  results  in  the  total  purchase  price  for  the  items.  The  second  change  is 
in  the  user  options  section.  The  option  for  Extended  Price  screen  has  been  changed  to 
Unit  Price  screen. 
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Vendor  Information  Screen 


dor  Data  For:  5905-01-009-5543 

D 

1  N 

S  E 

C  T 

D 

E 

L 

! 

1 

p 

R 

0 

B 

i 

1 

CAGE 

VENDOR 

56856 

6S313 

7K545 

Vamistor  Corp. 

G  &  A  Salas 

Hamilton  Avnet  Electronics 

91356 

92091 

92121 

1 

1 

1 

1 

1 

1 

1 

■ 

1 

1 

1 

1 

1 

■ 

■ 

■ 

■ 

1 

1 

1 

User's  Options: 

<U>  Unit  Pricing  <A>  Award  Screen  <C>  CDCF  Vendor  Detail 

■E>  Extended  Pricing  <Q>  Quit  <P>  Problem  Vendor  Detail 


The  vendor  screen  display  the  vendor  delivery  information  and  informs  the  user 
if  the  vendor  was  found  in  any  of  the  supporting  data  files.  On  the  left  side  of  the 
screen,  the  cage  code  is  located.  Next  to  that  is  the  name  of  the  vendor.  After  the 
vender  identification  section,  discount  information  is  given  and  delivery  information  after 
that. 

'DEL'  is  the  projected  delivery  date.  The  vendor  quotes  a  delivery  time  for  his 
products.  That  time,  in  days,  is  added  to  the  current  Julian  date.  In  addition  to  the 
delivery  time  an  administrative  lead  time  is  also  added.  The  projected  delivery  date  is 
now  compared  to  the  required  delivery  date  entered  by  the  user  at  the  input  screen.  If 
the  projected  delivery  date  is  prior  to  the  RDD,  the  delivery  date  is  displayed  in  green. 
If  the  vendor  cannot  meet  the  RDD.  the  delivery  date  is  displayed  in  red. 
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The  final  section  of  the  vendor  information  display  area  identifies  what  data  files 
the  vendor  is  reported  in.  ’SPEC’  indicates  the  vendor  is  coded  as  something  other  than 
large.  ’PROB’  is  marked  if  the  vendor  appears  in  the  DCRL,  problem  vendor  file. 
’CDCF’  reports  the  existence  of  the  vendor  in  the  Customer  Depot  Complaint  File,  and 
’QUAL’  identifies  this  vendor  as  being  on  the  quality  vendor  list. 

As  before,  abnormalities  identified  by  the  system  are  mdicated  in  the  upper  left 
hand  corner  of  the  screen.  All  valid  user  options  are  indicated  at  the  bottom  of  the 
screen. 
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DCRL  Screen 


6S313 

SECOM  ELECTRONICS  CORP 

12  PROGRESS  PLACE 

JACKSON  NJ  08527-3002 

89/11/15  D  Pre-Award  Survey  Required 

/** /** 

«*^**y** 

**  y**  y*-* 

SEE  P  lOM  20  OCT  89  RE  UNSATISFACTORY  PERFORMANCE 
RECOMMEND  DETERMINATION  OF  NONRESPONSIBILITY, 
PREAWARD  SURVEY,  OCAS  ADMINISTRATION 


Press  any  key  to  continue _ 


This  is  the  DCRL  screen.  If  a  bidding  vendor  appears  in  the  DCRL  file,  the  cage 
code  is  highlighted  red.  To  see  the  information  contained  in  the  file,  the  user  enters  'P' 
from  any  of  the  user  screens  and  the  discrepancy  details  for  that  vendor  appears  on  a  this 
screen.  This  screen  displays  all  the  information  on  file  for  that  vendor.  When  the  user 
finishes  reviewing  the  data,  striking  any  key  will  return  the  program  to  the  previous 
screen. 
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CDCF  Screen 


6S313 


I  DISC  -->  Q5 

CAUSE  ->  CN  CONTRACTOR  NONCOHPL lANCE  (PRIME  CONTRACTOR) 

DISP  -->  AD  DALE  -  CAT  I  -  DAC  FROM  C/C  "K"  TO  C/C  "H"  W/MGMT  CODE  " 
CORR  -->  AO  POC  BETTY  GEBELE/0SI8/AV986-6A86. 


Press  any  key  to  continue... 


The  Customer  Depot  Complaint  File  is  a  listing  by  NSN  of  items  that  have  had 
complaints  registered.  The  complaint  can  be  anything  from  substandard  product 
performance,  to  mis-marked  packaging.  The  software  incorporates  this  data  tile  using 
the  following  method.  First,  the  system  checks  for  the  existence  of  the  NSN  in  the 
CDCF  data  file.  If  the  NSN  exists,  a  search  is  conducted  within  the  NSN  for  a  cage 
code  matching  any  of  the  bidding  vendors.  If  a  bidding  vendor  is  found  to  have  a 
complaint  filed  on  the  product  in  question,  the  system  color  codes  the  vendors  cage  code 
in  the  display  screens.  There  will  also  be  a  mark  in  the  ’CDCF’  column  for  that  vendor 
on  the  Vendor  Information  screen. 

By  selecting  'C  from  the  options  menu  the  user  can  call  up  the  above  screen  for 
the  affected  vendors.  Pressing  any  key  will  continue  to  call  up  multiple  entries.  When 
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all  information  has  been  displayed,  the  system  return  the  user  to  the  screen  that  the  user 
entered  the  ’C’  option. 
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Award  Screen 


Award  Information  For:  5905-01-009-5543 


Press  <P>  For  Previous  Screen 
Any  Other  Key  When  Finished 


The  final  screen  available  to  the  user  is  the  Award  screen.  Through  the  use  of 
the  other  screens,  the  user  makes  a  determination  as  to  which  vendor  should  receive  the 
contract  award.  Once  the  determination  is  made,  entering  an  'A'  for  the  user  option 
allows  the  user  to  enter  the  cage  code  of  the  vendor  receiving  the  award.  Once  entered, 
the  system  displays  this  screen.  On  it,  is  all  the  information  the  user  needs  to  complete 
the  DESC  Form  800.  This  includes  the  vendors  business  and  billing  addresses,  vendor 
type  code,  discount  information,  delivery  data,  and  quoted  prices  for  this  vendor. 

The  user  can  either  press  a  'P’  if  he  wishes  to  return  to  the  information  screens 
or  any  other  key  will  return  the  system  to  the  Program  Information  screen. 
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The  user  can  terminate  use  of  the  system  at  several  points  along  the  way.  At  the 
data  entry  screens  two  escape  key  presses  <  ESC  >  <  ESC  >  will  interrupt  execution 
while  entering  the  NSN.  Entering  a  zero  Quantity  will  return  the  program  to  the 
Program  Information  Screen  as  well. 

When  the  user  advances  to  the  information  screens,  entering  a  ’Q’  from  the 
options  menu  will  return  the  system  to  the  Program  Information  Screen.  The  program 
automatically  sends  the  user  to  the  Program  Information  Screen  after  the  award  screen 
is  selected,  unless  told  to  do  otherwise. 

Once  the  user  arrives  at  the  Program  Information  Screen,  he  has  the  option  of 
either  entering  a  'Y'  and  reinitializing  the  system  for  another  inquiry,  or  a  'N'  can  be 
entered  to  return  to  the  dBase  dot  prompt.  Entering  ’QUIT’  at  the  dBase  prompt  will 
return  the  computer  system  to  the  DOS  prompt. 


The  Model  Component 


The  model  data  file  controls  how  and  when  specified  information  is  presented  on 
the  screen.  The  values  contained  within  ihe  model  can  be  changed  by  the  system 
administrator.  For  information  on  updating  data  files,  consult  your  dBase  reference 
manual.  The  following  is  controlled  by  the  contents  of  the  model  data  base. 

a)  Low  Price  Flag.  This  element  alert  the  user  when  the  vendor  is  quoting  a  price 
that  is  significantly  lower  than  the  competitors.  When  set,  the  low  price  will  be 
displayed  in  yellow  on  the  pricing  screens. 

b)  No  History  Flag.  The  number  stored  in  this  element  represents  a  dollar  threshold 
value.  If  the  unit  price  of  an  item  exceeds  this  amount,  and  there  is  no  historical 
purchase  information  on  file,  a  message  is  printed  on  the  output  screens. 

c)  Exceeds  History  Price.  The  prototype  compares  the  item’s  current  unit  price  with 
the  unit  price  of  the  item  when  last  ordered.  If  the  current  unit  price  exceeds  the 
last  unit  price  by  more  that  the  percentage  contained  in  this  element,  a  message 
is  presented  to  the  buyer. 

d)  Excessive  Contract  Value.  If  the  total  value  of  the  award  exceeds  the  dollar 
amount  stored  in  this  element,  a  warning  is  printed  on  the  screen  informing  the 
user  the  limit  for  small  contract  award  has  been  exceeded. 
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Variation.  On  the  price  lists,  the  vendor  identifies  any  variation  in  shipping 
quantity.  The  vendors  claim  authorization  to  ship  a  quantity  within  a  stated 
percentage  of  the  contract  quantity.  For  example,  a  vendor  may  claim  a  variation 
of  two  percent.  If  the  contract  was  written  for  one  hundred  units,  the  vendor 
could  ship  only  ninety-eight  units  an  still  satisfy  the  contract.  The  prototype 
check  this  variation,  internally  increments  the  quantity  ordered  to  account  for  the 
variation,  and  computes  the  resulting  award  value  of  the  contract.  If  the  award 
value  exceeds  the  excessive  contract  value,  defined  above,  a  warning  is  displayed 


on  the  user  screens. 
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